Cream of the Crop 12

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 12 / Cream of the Crop 12 (Part II) / Cream of the Crop 12 (Part II).iso / BBS / NANO116.ZIP / NANOBBS.DOC < prev next >

Wrap

Text File | 1996-02-04 | 235.0 KB | 6,482 lines

▄█████▄ ▄█████▄ ▄█████▄ ▄████▄ ▄█████▄ ▄█████▄ ▄████▄ ▄▄▄ ▀███ ▄▄▄ ▀███ ▄▄▄ ▀███ ▄▄▄ ▀███ ▄▄▄ ██▀ ▄▄▄ ██▀ ▄▄▄ ▀▀▀ ███ ███ ███ ███ ███ ███ ███ ███ ██████▄ ██████▄ ▀████▄ ███ ███ ████████ ███ ███ ███▄ ███ ███ ███ ███ ███ ▄▄▄ ███ ███ ███ ███ ███ ███ ███ ▀████▀ ██████▀ ██████▀ ▀████▀ NanoBBS 1.16 Copyright 1993-1996 Whirlwind Software All Rights Reserved Programs and Documentation by Gerald T. Albion - Additional Code by - Mark Dignam and Mark May - Beta Testers - Don St. Germain "Big Bad" John Barnard - Numerous Helpful Suggestions Provided by - Allen Walker Patrick Wilson Ryan Clifford Brent Boudreau - This product uses - JAM(mbp) - Copyright 1993 Joaquim Homrighausen, Andrew Milner, Mats Birch, Mats Wallin. ALL RIGHTS RESERVED. - Special thanks to - The users of THC BBS, Victoria, BC for their endless patience and priceless assistance in the development of UFO and NanoBBS. This document contains references to many trademarks. Whirlwind Software acknowledges ownership of all such trademarks by their respective owners. NanoBBS 1.16 Documentation Page 01 CONTENTS Introduction ........................................ 3 Version Numbering ................................... 6 System Requirements ................................. 7 Setting Up NanoBBS .................................. 8 - 10 Step Installation ............................ 9 - Command Line Switches ........................... 11 The Configuration File .............................. 13 Message Areas ....................................... 30 - Examples ........................................ 30 - Keyword Reference ............................... 32 File Areas .......................................... 35 - Examples ........................................ 35 - Keyword Reference ............................... 37 Doors ............................................... 39 The Black Art of Batch File Writing ................. 42 NanoBBS Utility Programs ............................ 54 External Files ...................................... 55 - Various Configuration Files ..................... 55 - FILES.BBS ....................................... 58 - Semaphores ...................................... 61 - ASCII/ANSI/RIP files in /BBS/MISC ............... 62 - NanoCHAT external files ......................... 65 Keys While The User Is Online ....................... 66 A Tour of the WFC (Waiting For Call) screen ......... A Tour of the user editor ........................... A Tour of NanoBBS's canned main menu interface ....... 68 Language Files - Customizing almost Everything! ..... 73 Embedded Colour Commands ............................ 78 NanoCHAT - Setting up NanoBBS as a chat system ...... 80 Glossary ............................................ 93 Contact Information ................................. 99 NanoBBS 1.16 Documentation Page 02 ╔═╦═══════════════════════════════════╦═╗ ║ ║ Introduction: What -is- NanoBBS? ║ ║ ╚═╩═══════════════════════════════════╩═╝ NanoBBS is a highly configurable BBS package. Its features include: - User-visible output is configurable via language files - UFO, a powerful scripting language with access to virtually all system and user variables - Built-in NanoCHAT, a teleconferencer based on Whirlwind's TommCHAT teleconference door. You don't pay extra for multiuser chat with NanoBBS! - Your choice of *.MSG, Squish, or JAM message bases - Up to 65535 message areas and 65535 file areas - Full internal support for CD-ROMs including a fast copy-to-temporary-file function and alternate FILES.BBS directories - Users can embed colours in messages - An internal full screen message editor - High speed file searching and new-file scans - Works up to 115200 bps with or without a FOSSIL - Convenient internal user editor - Sysop-definable time limits by access level - Account expiry can be set for any date - Doors can be age-restricted, no worries about minors playing adult doors! - File areas and message bases can be restricted by age - give users adult access on their 21st birthday automatically! - Message bases can be restricted by gender, for "ladies only" echoes etc. - Users may logon with real name, pseudonym or user number, whichever is easiest! - New User Password and System Password features add virtually impenetrable extra security to private systems! - SysOp can select between a canned hardcoded BBS or build a completely new one using UFO scripting - Lists (file areas, message areas, users, etc) can be automatically displayed in one, two or three columns - Multi-node aware and Desqview friendly! Node numbers can even be passed to doors! APPEARANCE: IF UNIQUENESS IS IMPORTANT TO YOU! Although NanoBBS excels in many areas, it is designed first to give its sysop the maximum flexibility in configuring the function and appearance of the BBS. The UFO scripting language allows you to build entire menus and call upon virtually all functions of the BBS from within a text file! And, the messages that would normally be hardcoded in other BBSes are located in a RAM-based language file which can be modified or totally rewritten as the SysOp sees fit! What's more, NanoBBS does not require an ANSI driver like so many other lesser BBSes, in fact NanoBBS 1.16 Documentation Page 03 it doesn't even need separate ANSI and ASCII files for system text files, although it does allow the separate files. If a user has ANSI turned off, the BBS can strip ANSI codes on the fly, and even expand horizontal ANSI cursor movements into spaces or backspaces as needed! Of course, automatic ANSI detection is standard and can be turned off if desired! Random welcome screens are also a supported standard feature! And a comprehensive RIPScrip suite is built into the UFO script language and in the system language files, so that you can make RIPScrip screens in plain English without buying an expensive "Rip Draw" type of program. And, there are forty sysop-definable sysop keys for ultimate convenience! SECURITY: TAKE CONTROL OF YOUR BBS! NanoBBS is also designed with security in mind, with NUPs and system passwords, and the ability to restrict message areas based on age and sex, and file areas based on age. These features alone make NanoBBS ideal for an adult BBS or an exclusive private system, but once you've moulded NanoBBS's form and performance to your ideal image you'll want to put it online for everyone to use! The BBS also supports "expiring" accounts which allow a time-limited access level, which takes all the work out of keeping track of accounts on pay systems! You can set accounts to expire anywhere from a day to 50 years in the future, or you can have no expiry date at all! You can also select which questions in the new-user questionnaire are required and which ones are optional, and even which ones will be asked at all! All file areas can have a different directory set for uploads than for downloads, allowing the sysop to screen uploads in private before making them available to users! This prevents pirated programs from being distributed on your BBS without your knowledge! There are also "barricades" which let you unobtrusively and judiciously remove certain individuals from certain message areas without otherwise lowering anyone's access. A programmable "trashcan" and "message censor" round out the list of features designed to protect you and your BBS from abuse! HIGH SPEED FILE SECTIONS! NanoBBS is also designed with very large file sections in mind! With the author's own BBS totalling over 2 gigs online, the problems of quickly finding and accessing files on a large system are all too evident. So, a number of special caching routines and high-speed file indices have been implemented to give the maximum search and retrieval speed possible! If you run a small or average BBS, searches will be nearly instantaneous. The author's BBS has some 25,000 files and any one can be located in seconds! In addition, you can set any file area to be a CD-ROM area! You can set a directory for FILES.BBS that is separate from the CD so that you will be able to remove files that you don't want users to access, or change the descriptions! Downloads from NanoBBS 1.16 Documentation Page 04 CD-ROM areas are accomplished by first copying the file(s) from the CD to a temporary directory, to minimise the problems of speed and system resource usage that arise from directly downloading from a CD. SysOps who want to preview a CD without taking the BBS down can hit a "CD OUT" key at the wait-for-call screen, and immediately all CD file areas are shut off, allowing you to change the CD and examine another one without worrying about a user trying to access a file on the one you just took out... Of course, file upload/download ratios by kilobyte are also supported, giving you complete control over file leeches! NanoBBS 1.16 Documentation Page 05 ╔═╦═══════════════════╦═╗ ║ ║ Version Numbering ║ ║ ╚═╩═══════════════════╩═╝ NanoBBS version numbers can be used to distunguish one version from another in the following ways: 1.00a | ||| | ||| Major Revision ---------' ||| Minor Revision -----------'|| Maintenance Release -------'| Bug Fix --------------------' So, for example, 2.00a differs from 1.00a in that 2.00a is a Major Revision, for example the structure of one or more data files has changed, or some new feature or set of features has been added that drastically improves or changes NanoBBS's appearance and function. Likewise, 1.10a is different from 1.00a in that 1.10a has new features, for example a new file searching mode or a new message base format. 1.02a is different from 1.00a in that 1.02a is a maintenance release. This means some improvement to the existing function of the BBS, for example the reduction of memory usage for a particular function or the improvement in the speed of some part of the BBS. 1.00b is different from 1.00a in that 1.00b contains fixes for bugs that existed in 1.00a. The "Maintenance Release" part of the version number is always an even digit (0, 2, 4, 6, or 8) if the version is a full public release of the software, and is always odd if the version is a wide beta or a private beta. Thus, 1.14 is an official release, whereas 1.15 is a beta that will eventually become 1.16. All these are just examples. As NanoBBS evolves, there will no doubt be many different version numbers. NanoBBS 1.16 Documentation Page 06 ╔═╦═════════════════════╦═╗ ║ ║ System Requirements ║ ║ ╚═╩═════════════════════╩═╝ - An 80286 or better IBM compatible computer with at least 512k RAM - At least 20 megabytes of hard disk space (recommended) - A modem, any speed (at least 14400 recommended) - A standard serial port, or a multi-serial board with a special FOSSIL driver - A FOSSIL is NOT required! - A flat-ASCII text editor such as QEdit or the DOS full screen editor is a must for editing configuration files - An external Message Editor such as MsgEd or GoldEd is recommended - An external File Area Manager such as FEBBS or Fido-Fam is recommended - A RAM Disk of at least 400k for each node is highly recommended for swapping. NanoBBS uses 16-bit 80286 code. It will not run on an 8088 or other 8-bit machine. NanoBBS 1.16 Documentation Page 07 ╔═╦════════════════════╦═╗ ║ ║ Setting up NanoBBS ║ ║ ╚═╩════════════════════╩═╝ NanoBBS can be run "out of the box" by taking a few very simple steps. OK, if you're totally new at this, then maybe the steps won't seem all that simple, so I will try and make this as painless as possible. Because it is impossible for me to predict the numerous configurations of computers, software, and paths that NanoBBS will be installed on, I can only give general installation instructions. If you find you just can't get NanoBBS going no matter what you do, first re-read these instructions and make sure you haven't missed something, then if that doesn't succeed ask someone else who is running NanoBBS if they have had a similar problem and how they solved it. If that doesn't work (or if you can't find someone else who runs the software successfully) then feel free to drop me a line by netmail or on my BBS (see the "Contact Information" at the end of this document). Be specific about what's happening with your system - I may ask for copies of your config files etc. To contact me, see the netmail address and BBS phone number at the end of this file. If this is the first time you have installed NanoBBS, be warned that NanoBBS will try to install itself in the C:\BBS directory. You can move it to another directory after it is installed, but you'll need to change the paths in all of your configuration files if you do this. Before you install NanoBBS, make sure your system meets the following minimum requirements: - You need a hard disk with at least several megs free. - You need about 380 kilobytes of RAM free. This is inconsequential for most installations, but it might be an issue if you are using a multitasker such as DesqView. - You need a FOSSIL driver, revision 5 or later. Several common FOSSILs are X00, BNU, and OpusComm. The FOSSIL must be installed and available before NanoBBS is able to run. Check your FOSSIL documentation for installation instructions. - You need to be running DOS, either MS-DOS or PC-DOS. I have received mixed reviews of NanoBBS's installability under Win95 and OS/2 Warp, so your mileage may definitely vary. Good thing NanoBBS is shareware! However, because I don't use Win95 or Warp, I cannot offer support for NanoBBS installations under these operating systems. NanoBBS 1.16 Documentation Page 08 ┌──────────────────────┐ │ 10 Step Installation │ └──────────────────────┘ ┌───┐ │ 1 │ To install NanoBBS, just run INSTALL.EXE. The install └───┘ program will unpack the program files, and will then determine whether it needs to also install the ASCII and ANSI and RIP files, and whether it should install default configuration files. It will also install and compile the language files. Once INSTALL is complete, you need to take the following general steps, which will be explained in much greater detail later in this manual... ┌───┐ │ 2 │ Edit NODE1.CTL (using an ASCII text editor or word └───┘ processor in ASCII mode) to your specifications. Set the proper paths, com ports, baud rates, modem control and response strings, default access levels, events, and everything else that needs to be adjusted to your requirements. NODE1.CTL is the main configuration file containing most of the general setup of the BBS. See the chapter titled "The Configuration File" for a complete explanation of the use of this file. Since NanoBBS is a multi-line system, NODE2.CTL is also installed by the INSTALL.EXE program. Both control files are automatically edited by the INSTALL.EXE program to fit the path you have chosen for the BBS's "system" directory. ┌───┐ │ 3 │ Edit MSGAREA.CTL to your specifications. MSGAREA.CTL is └───┘ the file which defines your message areas. Make sure to specify correct paths, access levels, and to use the message base type (Squish, JAM or *.MSG/Fido) which best suits your needs. And of course feel free to add or remove as many message areas as you like; there can be up to 65,536 of them! See the chapter titled "Setting Up Message Areas" for a complete explanation of this file. ┌───┐ │ 4 │ Edit FILEAREA.CTL to your specifications. FILEAREA.CTL └───┘ is the file which defines your file transfer areas. As in the message area file, make sure you specify all the right paths and access levels. Make sure all those paths exist and that there is a FILES.BBS file in each one containing a list of all the files in the area and their descriptions. As with the message areas, there can be up to 65,536 file areas! See the chapter titled "Setting Up File Areas" for a complete explanation of this file. NanoBBS 1.16 Documentation Page 09 ┌───┐ │ 5 │ Edit DOORS.CTL to your specifications. DOORS.CTL is the └───┘ file which defines your "Doors" or external programs which are accessible by the users. Doors are usually games but they can also be interfaces to special databases, "expert" advisory systems, call-back verifiers, or have any number of other functions. ┌───┐ │ 6 │ Type CONFIG NODE1 at the DOS prompt and hit Enter. This └───┘ will convert the four files I just described into a form that is more readily usable by NanoBBS. This process is called "compiling configuration". If you already have files in the file areas you have defined, then you must also type BBS /F at the DOS prompt to create the file area indexes that allow your callers to find files for downloading. ┌───┐ │ 7 │ Once this is complete, if all the paths are correct (and └───┘ they all exist) you should be ready to go. Note that the paths do not HAVE to all be defined; NanoBBS will warn you wherever it cannot find a specified path. Now, just type BBS at the prompt and go through the new-user login procedure. Make an account for yourself. Most sysops traditionally make the first account in the system theirs; that makes you user 0 (zero). ┌───┐ │ 8 │ Try logging in; you should be able to navigate the system └───┘ as a new user right away. Hit Alt-E to enter the user editor and give yourself SysOp access (the access and keys you have defined in NODE1.CTL for SysOp access) or better! Don't be surprised if NanoBBS says it can't find your message areas and that it's trying to create them. This is normal the first time out, or whenever the message areas don't actually exist yet. ┌───┐ │ 9 │ If you're only going to run one node, you can skip this └───┘ step. If you run more than one node, you can run multiple copies in the same system directory (the directory specified by the SYSPATH statement in NODE1.CTL) but each copy has to have its own config file. So, for example, if you are running two nodes, you should make a copy of NODE1.CTL and call it NODE2.CTL (Or use the NODE2.CTL that is included and edit it to fit your needs). Edit NODE2.CTL so that its node number, com port and modem settings match those of your second node, and compile it by typing: CONFIG NODE2 /Q at the DOS prompt. The /Q tells CONFIG to ignore the MSGAREA.CTL, FILEAREA.CTL and DOORS.CTL files as these can NanoBBS 1.16 Documentation Page 10 be shared between the two nodes. If you've just compiled all these area files, you don't need to do it again until you edit them. Repeat this procedure for as many nodes as you have. If your nodes are spread out across a LAN, make sure each one specifies a local com port and that all the system and similar paths point to the system directory on one central machine. Otherwise NanoBBS will start creating user log files all over the LAN and the nodes won't be able to communicate with each other. ┌────┐ │ 10 │ Now create the batch file(s) necessary to run the BBS. └────┘ If you are running under DesqView or another multitasking environment like OS/2, you should predefine special task configurations for each node. To run each node, you should have a batch file for each one, and each node must be called with a /C command line parameter specifying the compiled configuration file that the node should use. This is all covered exhaustively in "The Black Art of Batch Files", elsewhere in this manual. Once all of this is done, you should be able to run your BBS reliably from your main BBS/Mailer batch file or by running your multitasker (if its default macro calls the batchfiles for each node). You will, of course, want to customize the ASCII, ANSI and RIP files in the MISC directory so that they reflect the character and style of your BBS! ┌───────────────────────┐ │ COMMAND LINE SWITCHES │ └───────────────────────┘ /F{filename.dat} builds the index files necessary for the speed performance of NanoBBS's high-speed file finding functions. Without running BBS /F, NanoBBS will still be able to find files the old-fashioned way (by actually reading through every line of the FILES.BBS files) but this process is much slower. Once the index files are in place, NanoBBS will only be able to find files which are listed in the indices. This means that newly-uploaded files won't be available until BBS/F is run again. If you don't have a huge file section you may be able to get away with running BBS /F each time NanoBBS exits after each call, but on many systems this will take too long and is better left to a nightly event. The filename.dat is the file name of the compiled file area file, usually FILEAREA.DAT. If the filename is left off, the program assumes FILEAREA.DAT. NanoBBS 1.16 Documentation Page 11 /R This builds a special version of MASTER.FIL called CDROM.FIL. CDROM.FIL lists all the files in all the areas you have marked as "CDROM". While CDROM.FIL is not used directly by the BBS, it is "imported" into MASTER.FIL when you run BBS /F. This way, you need only index the CD-ROMs once - saving a great deal of time whenever you need to re-index the whole file base. This feature is extremely useful if you have many CD-ROM drives or if your CD-ROM drives are slow. Each time you add or change CD's, update the file area config file and recompile it with MFB. Then run BBS /R to index the CD-ROM areas. Then run BBS /F to incorporate the CD-ROM areas into the main MASTER.FIL. ┌─────────────────────────────────────────────────────────────┐ │ If your users report mysterious bogus files in a FILES.BBS │ │ listing, especially at the beginning, this is an indication │ │ that the File Indices have fallen out of sync with the │ │ FILES.BBS. The solution is to run BBS /F. │ └─────────────────────────────────────────────────────────────┘ /E Invokes the user editor. /T{time} indicates to NanoBBS that the mailer needs to be back online in {time} minutes - this is used to force mail events. If necessary, NanoBBS will adjust the user's time online and advise her accordingly. /C{config.ext} will cause NanoBBS to load the compiled config file specified. If this is omitted, NODE1.DAT is assumed. If no extension is provided, .DAT is assumed. So, BBS /Cnode2 would run the BBS using NODE2.DAT which contains the parameters of NODE2.CTL. /W causes NanoBBS to wait for a caller. /A causes NanoBBS to go into "NanoWatch" - a multi-node status monitor. From NanoWatch you can monitor the activity of up to 20 nodes, or log in locally with Alt-L, or enter the user editor with Alt-E. /B specifies a baud rate. This is used when passing off from a mailer or other front end. You should have a SPAWN.BAT or similar batch file generated by your mailer which specifies, among other things, this baud rate. When this switch is used, the connection is assumed already made and the BBS goes directly to the logon procedure. If neither the /A or /B or /W switches are used, NanoBBS assumes this means it is a local session - it will not use the modem at all, but will get its input solely from your keyboard and will send its output solely to your monitor. NanoBBS 1.16 Documentation Page 12 ╔═╦════════════════════════╦═╗ ║ ║ The Configuration File ║ ║ ╚═╩════════════════════════╩═╝ COMPILING THE CONFIGURATION FILE NanoBBS uses a flat ASCII text file for system configuration, as this approach provides the greatest flexibility and the ability to add comments, so that you can rationalise your choices later. By default, NanoBBS uses the file NODE1.DAT - referring to the fact that by default NanoBBS is node 1 of a multi-user system, even if your BBS has only one line. To create NODE1.DAT, you must first compile NODE1.CTL with the CONFIG.EXE program. CONFIG reads the configuration file, line by line, and compiles the text file into a fast machine-readable file format and writes it out to a .DAT file. To make multiple nodes you need a config file for EACH node. So, for example, if you have two nodes, you would first edit NODE1.CTL to your specifications for Node 1, including the com ports and the external events you want that node to process. Then, make a copy of NODE1.CTL, and name the copy NODE2.CTL. Now edit NODE2.CTL to the parameters required for Node 2, including the com port, baud rate and so forth. Once this is complete, you must then run the CONFIG program once for each config file. It is worth noting that you can save some time by only doing a "full" config on one node. Allow me to illustrate: C:\>config node1 C:\>config node2 /q If you type these two commands at the dos prompt, CONFIG.EXE will first compile NODE1.CTL into NODE1.DAT, and will also configure the message area files, file area files and door configuration files by calling the MMB.EXE, MFB.EXE and MAKEDOOR.EXE programs for you. The second command just compiles NODE2.CTL into NODE2.DAT. The /q parameter tells CONFIG.EXE not to bother compiling the file areas and other files a second time, which is unnecessary when these files are to be shared between nodes - the normal multi-node operating mode. SYNTAX OF THE CONFIGURATION FILE The configuration file itself is a plain ASCII text file with one command per line. "Commented" lines are ignored, as are blank lines and lines which start with unrecognised words. The best way to comment out a line is to start the line with a semicolon ";". Several options (like WIDEOPEN) come commented out by default; to activate such options you have to "uncomment" them by deleting the leading semicolon. The commands are not NanoBBS 1.16 Documentation Page 13 case sensitive, but take care to type the text parameters (such as the BBS name in the SYSTEMNAME line) exactly as you want users to see them. Examples: ;This line is commented out. This line is not. The sample configuration file is commented with explanations of those commands which I do not consider self-evident, but I will explain each one in depth here. I'll include at least one example for each one. ┌─────────────────────────────────────────────────────────────┐ │ General System Options │ └─────────────────────────────────────────────────────────────┘ The NODE parameter specifies which node number the BBS will use for multi-user functions such as NanoCHAT. If you are running a one-line BBS this should be set to 1. Node 1 The SYSTEMNAME parameter is the name of your BBS as you want it passed to doors in the DORINFO1.DEF file, and in other places yet to be supported... SystemName Whirlwind BBS The SYSTEMCITY parameter is the location of your BBS; this should be the city and state or country it is located in, e.g. "Victoria, B.C." or "Peoria, Illinois" or "Paris, France". SystemCity Victoria, B.C. The SYSTEMPHONE parameter is your BBS's phone number. If you're running a multi-line BBS with more than one phone number, I see no reason why you can't have a different number for each node. SystemPhone 604-361-4549 The SYSOP parameter is your name (or pseudonym). This is the name to which Feedback or and private message to "SYSOP" will be addressed. It is also used by the DORINFO1.DEF door file. Sysop Tommy The SHOWUPLOADER parameter tells NanoBBS to include the name of the person who uploaded a file in that file's description. If the SHOWUPLOADER keyword is commented out, NanoBBS will not NanoBBS 1.16 Documentation Page 14 automatically append the line "Uploaded By: {UserName}" to file descriptions that are uploaded by users. By default this feature is ON, i.e. users get public notice for uploads. This is a GoodThing(tm) since it encourages uploading. showuploader This is the definition of the "Spinny Cursor" used in long message searches. This example gives a classic "twirling stick" spinning cursor which rotates counter-clockwise. This can be up to 16 characters long. Spin \-/| This determines whether you want to enable multi-user chat features. This should be commented out if you are running a 1-line system or if you do NOT want to use multi-node chat! MultiNode ┌─────────────────────────────────────────────────────────────┐ │ Paths and Filenames │ └─────────────────────────────────────────────────────────────┘ The SYSPATH is the path to the BBS executables, language files, user log, and all miscellaneous system files. The INSTALL.EXE may automatically change this (and several other paths derived from it) to the one you select when you first install NanoBBS. Note; if this is missing the BBS will try to read everything from the directory where the executable lives. I have not tested this eventuality extensively but it does seem to work for me, however I wouldn't recommend relying on it. Use this parameter! SysPath C:\BBS\ This is the path to the .ASC, .ANS, .RIP and compiled UFO (.BBS) files. It is also the path to the NanoCHAT help files and the NanoCHAT /m and /i info files and messages. TextPath C:\BBS\MISC\ The SWAPPATH is the path to a directory where you want Swapping files to go. Each time NanoBBS runs a door or other external program such as an archiver, it tries to swap itself out to EMS (if the SwapEMS parameter is active) or to disk. This sets the path for disk swaps. If you have enough memory but not EMS, use a RAM disk - it is still much faster than swapping to disk! SwapPath F:\ SwapEMS NanoBBS 1.16 Documentation Page 15 This is the path to the IPC files. If you don't use multi-user chat you needn't concern yourself with this, however if you do, then this should DEFINITELY be a RAM disk or a directory thereof! IPCPath F:\ The TEMPPATH is a directory where files from a CD-ROM are copied to before downloading. Most CD-ROMs are very slow compared to hard drives, so the user will find downloads faster and you will run less risk of file sharing problems if CD-ROM downloads are copied to a temporary disk directory and downloaded from there instead. If you're running a multi-node BBS, you should have a separate TEMPPATH for each node on your system. This is because the BBS deletes the entire contents of the temporary directory after each logoff, to avoid filling your hard disk with files from the CD. TempPath C:\TEMP1\ The SCANPATH is the path to the individual user scan files. NanoBBS lets users select which message areas to include in QWK packets and global new-scans, and stores the list of included areas in a file for each user. Since a great many users could end up using this feature, a separate directory is necessary for these Scan files. ScanPath C:\BBS\MSGSCAN\ NanoBBS allows you to completely build a BBS from scratch in the UFO scripting language. Prior to version 1.11, this was accomplished (and largely under-documented) by placing UFO tokens in the LOGO and WELCOME files, bypassing the standard canned interface. Starting with version 1.11, NanoBBS now supports two UFO files which actually override the logon process and the canned main menu (from which all other canned functions are launched). The STARTFILE is intended to replace the logon procedure: it should contain keywords to first identify your BBS and greet the user, and then prompt for a username and a password, followed by a [loguser] keyword to actually log the user on. You can invoke the canned logon procedure from here or the canned new-user questionnaire (see UFO.DOC for information on the keywords needed to accomplish this) or use UFO to write completely original logon protocols! Similarly, the MAINFILE replaces the Main Menu. It is called right after the logon procedure (or the STARTFILE if you're using one). The MAINFILE might be something as simple as a data "answering machine" in which the only option is sysop feedback, or it could be a totally custom full-featured BBS, making use of canned features and your own custom versions as you see fit! If these keywords are active, the files are used, otherwise NanoBBS uses the canned equivalents. If you want to run a NanoBBS 1.16 Documentation Page 16 canned NanoBBS, leave these commented out! StartFile matrix.bbs MainFile mainmenu.bbs ┌─────────────────────────────────────────────────────────────┐ │ Modem Configuration │ └─────────────────────────────────────────────────────────────┘ You can embed special functions in all the modem commands. In the modem strings below, "|" (pipe) means carriage return, "~" (tilde) means delay 1 second, "'" (apostrophe) means delay 1/20 second, "^" (caret) means DTR up and "v" means DTR down... The COMPORT parameter specifies the com port, e.g. 1 for COM1:. It goes without saying that this should be different for each node. If this is set to 0 only local logons will be possible. ComPort 1 SLOWBAUD is the slowest baud rate allowed. I run a pretty easygoing system so I allow all baud rates, but you may not want slower modems tying up your shiny new V.34, so you can set a minimum (say, 2400 or 9600) using this command. If this command is commented out, all baud rates are allowed. This example allows baud rates as low as 300. SlowBaud 300 INITBAUD is the "default" baud rate; it is the baud rate to initialise the modem and wait for a call. InitBaud 38400 INIT is simply the string to initialise the modem. If your modem has an NV-RAM feature and is properly configured you should only need to use "ATZ|". This example does just that but also forces the speaker off. Consult your modem manual for an explanation of its commands! Init ATZ|~ATM0| Here's a modem init string which you might find suitable if your modem doesn't have an NV-RAM. In order of appearance, its function is to: Turn the speaker off, turn on "echoing" of modem commands, set verbose result code reporting, turn on normal carrier detection (many modems default to "carrier detect ON all the time no matter what the real carrier state is"), and set the modem to hang up if DTR is dropped. Init ATM0E1X4&C1&D2| INITRETRY is the number of times to attempt initialisation before returning a "Can't initialise the modem" error. InitRetry 5 NanoBBS 1.16 Documentation Page 17 RING is the string returned by the modem when the line rings. When NanoBBS detects this string from the modem while it's waiting for a call, it gets ready to answer the phone... Ring RING| RINGS is the number of rings to wait before answering - 1 will answer on the first ring etc. If you have Caller ID this MUST be set to 2 or more, so that the CID data stream can come through. Otherwise 1 is the best choice for most direct dial-in lines. Rings 2 ANSWER is the command to send to the modem to cause it to answer the phone. Answer ATA| This is the string returned by modem when the modem has initialised OK. When NanoBBS tries to initialise the modem it expects to get this string back; if it doesn't then there may be something wrong. OK OK| NOCARRIER is the string returned by modem when an incoming call's connection fails before NanoBBS gets out of waiting-for caller mode. If it receives this it will immediately go back to waiting for a call. NoCarrier NO CARRIER| INITTIME is the number of minutes between each re-initialisation of the modem. This should be done periodically just to make sure all is well with the modem. Every 10 or 20 minutes is fine. inittime 10 If uncommented, NOFOSSIL will force NanoBBS to not use a FOSSIL even if one is loaded. If you have a FOSSIL loaded, NanoBBS will try to use it unless you use this keyword! When this keyword is in effect, NanoBBS uses its own serial driver. nofossil The PORT keyword defines the address and IRQ of com ports used by the internal serial driver. You can define ports 1 thru 16. The first parameter after PORT is the com port number (one-based!), followed by the hexadecimal port address, followed in turn by the IRQ. The defaults are given here. I do not recommend using COM5 and up with these defaults, and you should check the hardware settings for COM3 and COM4 carefully before you use this table NanoBBS 1.16 Documentation Page 18 as-is. These settings are only used by NanoBBS's internal comm routines and have no effect if you are using a FOSSIL. Port 1 03F8 4 Port 2 02F8 3 Port 3 03E8 4 Port 4 02E8 3 Port 5 0000 0 Port 6 0000 0 Port 7 0000 0 Port 8 0000 0 Port 9 0000 0 Port 10 0000 0 Port 11 0000 0 Port 12 0000 0 Port 13 0000 0 Port 14 0000 0 Port 15 0000 0 Port 16 0000 0 ┌─────────────────────────────────────────────────────────────┐ │ Baud Rate Definitions │ └─────────────────────────────────────────────────────────────┘ In the baud rate definitions, the SET parameter selects the baud rate to reset the modem port to upon connection (this should be set to your locked baud rate for all bauds if your port is locked). The RATE parameter determines the rate used for calculating transfer times etc., the DISPLAY parameter is the rate as shown to the user, and the CONNECT parameter is the modem response string by which NanoBBS can recognise the baud rate. There should be one baud rate defined for each one that your modem supports. For example, a 2400 baud modem should be set up to recognize 300, 1200 and 2400 baud callers, even if you won't be allowing 300 baud. In fact, especially if you won't be allowing 300 baud; after all you want the BBS to be able to tell the prohibited baud rates when it sees them! Each baud rate is defined with a BAUD parameter followed by several subparameters and then terminated with an END. The following examples illustrate: Baud 0 Set 0 Rate 300 Display 300 Connect CONNECT| end NanoBBS 1.16 Documentation Page 19 Baud 1 Set 0 Rate 1200 Display 1200 Connect CONNECT 1200| end Baud 2 Set 0 Rate 2400 Display 2400 Connect CONNECT 2400| end Baud 3 Set 0 Rate 4800 Display 2400 Connect CONNECT 2400/MNP5 end ; and so on until... Baud 11 Set 0 Rate 28800 Display 28800 Connect CONNECT 28800 end ; The sample NODE1.CTL has all the baud rate definitions needed ; by a system served by a 28800 V.FC modem. ┌─────────────────────────────────────────────────────────────┐ │ Time Limits │ └─────────────────────────────────────────────────────────────┘ USRSTART is the starting time of the period when NanoBBS will answer the phone. This and USREND are useful for part-time BBSes. USREND is the ending time; after this NanoBBS will indicate that the phone has rung but will not answer. If these times are the same, then users are always allowed. UsrStart 00:00 UsrEnd 00:00 PAGESTART and PAGEEND define the starting and ending times when users will be allowed to make noise on your speaker by paging you. Outside these hours, the user will still be allowed to page, will still be asked for a reason, will still be logged, and the blinking "Paged" will still appear on the SysOp bar, but no sound will be made! Very useful for sysops who have to sleep in the same room with the computer! PageStart 08:00 PageEnd 23:00 NanoBBS 1.16 Documentation Page 20 LOGONTIME is the amount of time given to users to complete a logon after connection. This is in minutes. LogonTime 10 TIMEOUT is the number of minutes NanoBBS should wait at a prompt without any keyboard input from the user before it "times out" and terminates the session. Timeout 3 These are the maximum numbers of minutes which can be deposited and withdrawn from the time bank. max withdraw 60 max deposit 60 This keyword will cause NanoBBS to freeze the timer during message posting. post freeze This will include private messages and feedbacks when rewarding for posts. The POST FREEZE directive must also be active for this to have an effect. post reward private This keyword specifies the parameters for post rewards. The first number is the number of minutes to award for a short message. The second number is the number of minutes to award for a long message. The third number is the number of lines for a message to count as "long". This example gives a reward of 5 minutes online time for a post 1 to 7 lines long, and 10 minutes for a post 8 lines or longer. post reward 5 10 8 ┌─────────────────────────────────────────────────────────────┐ │ Security │ └─────────────────────────────────────────────────────────────┘ With all the competition out there on the BBS software market to have the most iron-fisted security, I thought it would be a nice complement to the security features to include an optional "UnSecurity" feature. By default it is commented out. The WIDEOPEN token will cause NanoBBS to skip the user logon process in the canned startup. You must use a logon UFO token NanoBBS 1.16 Documentation Page 21 to log users on or else all posts and log entries will be for user #0 "???". In the default file this is commented out, as in this example. ;WideOpen The NUP is the New User Password. If it is uncommented this password will be required for all new callers to be able to register as a new user. This is useful for invitation-only private systems. Since most BBSes are public, this option is "commented out" by default. ;NUP PASS This is the system password. It can be used as a security adjunct to the regular user passwords but its usefulness is more important in applications where there is no actual user logon, such as in an AE or other anonymous environment or a fast-turnover information providing system such as would be used on a 1-800 line. Used in conjunction with the WIDEOPEN parameter it can be used to create a very faithful emulation of AE. If commented out it is not used. ;SysPass CHANGEME The ECHOCHAR is the character echoed to the user when asking for a password. This applies to passwords at logon as well as to passwords asked when changing passords. EchoChar $ PASSWORDTRIES is how many tries a user gets at entering a password before being logged off and hung up on. To be fair to users, it should be at least 3 tries. PasswordTries 3 This is the access level needed to use the ! prompt: Access Bang 20 This is the access level given to new users: Access New 10 This is the key set given to new users. If commented out or if no keys are specified, then no keys are set for new users. In this example, keys 1, 2, 5, A, and C are set. NewKeys 125AC NanoBBS 1.16 Documentation Page 22 This is the access level needed to use various sysop functions. Access SysOp 5000 And the SYSOPKEYS parameter is the key set needed to use SysOp functions. SysOpKeys DEF This is the access level needed to get into the canned file section. Access Files 10 This is the access level needed to get into the canned email menu. Access Email 10 This is the access level needed to use the canned "read messages" menu option Access Read 10 This is the access level needed to use the canned doors menu. Access Doors 10 This is the access level needed to list today's calls. Access Todaylist 10 This is the access level needed to list users. Access Userlist 10 This is the access needed to use the batch files menu. Access Batch 10 This is the access needed to access NanoCHAT. Access Chat 10 NanoBBS 1.16 Documentation Page 23 This is the string used instead of the user's name when s/he posts anonymously. This can be up to 36 characters and may include embedded colours. anonymous ~E<~M<~O< ~PAnonymous ~O>~M>~E> The HIDESYSOP keyword is used by itself. When present, it instructs NanoBBS to "hide" logons by the sysop in both the callers-today list and the daily totals. The fact of the logon is still recorded in the NANOBBS.LOG and is also recorded in SECURITY.LOG. Off the record, this was added when the author noticed that he was inflating the daily call count by a factor of two during a brief period where he was cheating at a certain door game <grin>. hidesysop The NEW keywords define which new-user questions will be asked, and which ones will be "optional". Note that there is no real privacy justification for making the technical questions (lines, columns, ANSI, editor, language) optional so the option setting for those will be ignored by NanoBBS: either they're asked or they're not. .-----------------------------------------------------------------. | A little explanation: in most other BBS software, all of the | | new-user questions are mandatory - the user has to answer each | | question in order to proceed to the next and may not skip any. | | This fact is annoying to some sysops, particularly those of | | NirvanaNet(tm), a small FTN made up of "open systems" which the | | author briefly belonged to. To paraphrase their policy, if | | your BBS software doesn't support making questions like phone | | number, age and address optional or nonexistent, then you're | | expected to abandon it in favour of one that does. So, these | | keywords were created to fill that need. I may not be in | | NirvanaNet(tm) anymore, but my software is NirvanaNet(tm) | | friendly! | | -=( Tommy )=- | `-----------------------------------------------------------------' Valid options are DONTASK and OPTION. If a question is not present or commented out, it is both asked and required. By default, all of these are commented out, so that NanoBBS asks all of the questions and requires answers to all of them. This is the behavior of most other BBS programs. ; new realname option ; new location option ; new phone option ; new birthdate option ; new sex option ; new screen dontask ; new editor dontask ; new chknew dontask ; new language dontask NanoBBS 1.16 Documentation Page 24 This is the message area number of the default private message area. This is the message area to which Feedback is saved, where the BBS checks for new mail (if the user is set to check for mew mail at logon), and where the E-Mail area operates. By default it is 0 (zero) but there is no reason why it couldn't be set to some other area number. Make sure this area exists in your MSGAREA.CTL. Private 0 Uncomment this if you want credits to be deducted for time online If this is uncommented NanoBBS will behave like online services that charge by time online... The actual credit consumption rate is defined in LIMITS.CTL. Most BBSes do not need to uncomment this! ; Credit This is the "ratio threshold", or how much a user can download without uploading, before NanoBBS starts to enforce download:upload ratio limits. It is in kilobytes, so in this example a new user could download a total of up to 500 kilobytes before her file ratios are even checked. Threshold 500 This sets the amount of time, in percent, to give back to a user who has just successfully completed an upload. It is a percentage of the actual time spent uploading. A ULReward of 100 gives back 100% of the time spent uploading, or in other words the user will have as much time left after an upload as before the upload. In this default example we give a somewhat generous 300% time reward for uploading. ULReward 300 Normally, when a user uploads, the BBS gives the user an extra time reward immediately. However, you can set the BBS to deposit this credit to the user's time bank by using the BANKUPLOAD keyword. This will give you some control over the use/abuse of the upload credit. BankUpload This is the amount of time (in milliseconds) to wait for ANSI auto-detection. If your system is very slow you may want to extend this. Otherwise, set it as low as you can get away with without causing NanoBBS to fail to detect ANSi. A good default is about 500 milliseconds. AutoANSi 500 This is the number of seconds the user should have left when NanoBBS issues its first warning that the user is running out of time. It is entered in seconds, and in this example we have set it to 300 seconds, for a 5 minute first warning. Warn First 300 NanoBBS 1.16 Documentation Page 25 This is the number of seconds the user should have left when NanoBBS issues its second and final warning that the user is nearly out of time. It is also in seconds, and this example of 60 seconds provides a 1 minute final warning. Warn Final 60 If this is uncommented (default) Nano will ask the user to hit Enter upon connection. This is useful for when ANSi detection chronically fails due to slow modem responses. HitEnter ┌─────────────────────────────────────────────────────────────┐ │ Languages │ └─────────────────────────────────────────────────────────────┘ You can have up to 32 languages. Each language is identified by its base filename. For example, the language ENGLISH would refer to a pair of files called ENGLISH.LNG and ENGLISH.LDX, which are the message text and index files for the ENGLISH language. If the user has RIPScrip enabled, ENGLISH will refer to a different pair of files: ENGLISH.RNG and ENGLISH.RDX. NanoBBS needs to have a default language, so that it can display information before a user logs on. This is set to ENGLISH by default. ENGLISH is the only language file included with this version of NanoBBS, but third-party language files for other languages are encouraged. defaultlang english language 1 english ;language 2 hoser ;language 3 abusive ;language 4 r0dent ;language 5 francais ;language 6 deutsch ┌─────────────────────────────────────────────────────────────┐ │ Main Menu Command Overrides │ └─────────────────────────────────────────────────────────────┘ You can add or redefine up to 100 keys in the canned main menu to activate UFO script files. The UFO script files listed here must be found in the text file directory as specified above, and will have the .BBS extension appended automatically. Do not include the extension or path here. NanoBBS 1.16 Documentation Page 26 There are a couple of examples in the default NODE1.CTL file, and they are included here: ; ; Example: ; ; OVRKEY ! MODBANG ; ; This example replaces the canned bang prompt with ; MODBANG.BBS. ; ; You can also deactivate a main menu option by setting its ; filename to NIL, like this: ; ; OVRKEY D NIL ; ; This deactivates the canned doors menu off the canned ; main menu. ; ┌─────────────────────────────────────────────────────────────┐ │ File Menu Command Overrides │ └─────────────────────────────────────────────────────────────┘ FOVRKEY is like OVRKEY except that the keys override those in the canned File Section. There can be up to 30 FOVRKEYs. The example below displays the compiled UFO file IPLAQ.BBS when the user hits $ at the file menu. FOVRKEY $ IPLAQ What is this feature useful for? Well, if you wanted to run a custom file database door or a door for a CD-ROM which is not directly NanoBBS compatible, you can now make those things options from the file menu where they belong. To add a CD-ROM door to the file menu, take the following steps: [1] Set up the door according to the door's instructions. [2] Create an entry in DOORS.CTL for the door and compile it with MAKEDOOR. [3] Verify that the door works properly by entering it from the door menu. [4] Create a UFO script to call the door. You may want to put in tokens to restrict the use of the door. You will need to use the [rundoor] token to actually run the door. [5] Compile the UFO file. Make sure it's in your misc directory! NanoBBS 1.16 Documentation Page 27 [6] Edit your NODE1.CTL (and all other node config files!) to include the following entry: FOvrKey # CDROMDOR The above example will display/run CDROMDOR.BBS when the user hits # at the file menu. [7] Run CONFIG NODE1 (and again for each other node config file). [8] You should now have a working CD-ROM door in your file menu! ┌─────────────────────────────────────────────────────────────┐ │ QWK Parameters │ └─────────────────────────────────────────────────────────────┘ This is the path where QWK packets are assembled, disassembled, uploaded and downloaded. NOTE: This path should be unique to each node if you are running a multi-node system, or else some really weird crosslinks could occur if two users try to build QWK packets simultaneously... qwk path c:\bbs\qwk\node1 This is the base filename of QWK packets. This can be up to 8 characters. qwk bbsid NANOBBS Here are the compression program definitions. Although the external compression is mainly used by QWK, these same definitions are also used by the FILE_ID.DIZ extraction sub-system. The NAME is the archiver name as you want the user to see it, the Extension is the normal file extension by which files of that type are known. The ADD and EXTRACT commands must include the full path and .EXE or .COM extension in order to work. Since the compression is (in this version) only used for QWK processing, the ADD command should (ideally) specify "move"ing files into the archive rather than simply adding them, and the EXTRACT command should (definitely!) specify overwriting existing files. The ID bytes are as follows: the fist numeric parameter is the number of bytes from the first one where we are to find a string of bytes equal to the remaining specified bytes. 0 means the first byte. -1 means the last byte in the file, -2 means the second to last and so on. The remaining bytes are what the BBS searches for to identify the file type. A number of known archiver IDs are included in this sample file. You can specify up to 8 bytes to search for the ID. Byte values are in vanilla decimal, no hex here! There can be up to 16 compression programs defined, from 1 to 16. NanoBBS 1.16 Documentation Page 28 The syntax of the compression definitions is as in these examples. Start the definition with the COMPRESS command and the "slot" number for the compression definition. After you've specified the name, extension, ID bytes and the add and extract commands, end the definition with END. compress 1 name PKWare's PKZip extension ZIP add c:\bin\pkzip.exe -m %a %f extract c:\bin\pkunzip.exe -oe %a %f id 0 80 75 03 04 end compress 2 name PKWare's PKZip - Maximum Compression! extension ZIP add c:\bin\pkzip.exe -ex -m %a %f extract c:\bin\pkunzip.exe -oe %a %f id 0 80 75 03 04 end {Several examples from the default NODE1.CTL are deleted here for brevity} compress 7 name Rahul Dhesi's ZOO extension ZOO add c:\bin\zoo.exe -m %a %f extract c:\bin\zoo.exe -e:O %a %f id 0 90 79 79 end If you're running a multi-line system, it might be a good idea to put the compression configuration keywords in a separate file called COMPRESS.CTL and then put an INCLUDE keyword in each of your node configuration files pointing to COMPRESS.CTL. See the example below: Include Compress.Ctl ... this would take the place of all of the above if you have it all in a file called COMPRESS.CTL. Effective with verion 1.14, NanoBBS actually comes configured this way. You can move any part of the NanoBBS config file to another file by using Include directives. This would be useful for just about any config information that is global - the same for every node. NanoBBS 1.16 Documentation Page 29 ┌─────────────────────────────────────────────────────────────┐ │ Internet Arcana │ └─────────────────────────────────────────────────────────────┘ If your BBS is not in the Internet, you need not concern yourself with any of this. Most of this is included for future expansion only. While NanoBBS will write a valid RFC-1036 header to messages where required, there is no other direct support for the Internet or for Usenet. If you can get Internet running with these parameters using external programs, terrific! Otherwise, true internet support -is- forthcoming in a future version. If you use the RFC-1036 message header in any of your message areas, you should set all of these parameters to values which are valid for your system. This is the internet address of the system. There should be no @ in this IF YOU HAVE NO DOMAIN ADDRESS COMMENT THIS OUT! ; internet address horse.hockey.bull.roar.com This is used to build Usenet RFC1036 path header info. ; internet machine thc This is the time zone definition. The first parameter is timezone code as you want it displayed in RFC-1036 headers. The second parameter is the offset in hours from UTC in standard time, and the third is the offset from UTC in daylight time. These latter two parameters are not yet used by NanoBBS. timezone PST -8 -7 ┌─────────────────────────────────────────────────────────────┐ │ Hooks to MFB, MMB and MAKEDOOR │ └─────────────────────────────────────────────────────────────┘ These commands, if present, will call MMB.EXE, MFB.EXE or MAKEDOOR.EXE and conveniently compile those as well. It also lets you specify the use of non-standard filenames for these files, allowing you to associate a different set of file and message areas to different config files. uses files filearea.ctl uses message msgarea.ctl uses doors doors.ctl NanoBBS 1.16 Documentation Page 30 ┌─────────────────────────────────────────────────────────────┐ │ EVENTS │ └─────────────────────────────────────────────────────────────┘ Here are the "event" definitions. The first parameter is the absolute event record; it can be from 1 to 32. The second parameter is the day of the week the event is scheduled to take place (or "all" if the event should take place every day) and the third is the time, it 24-hour format. The fourth parameter is the errorlevel NanoBBS should exit with, and the remainder of the line (up to 60 characters) is the name of the event. You can signal that an event is "forced" - a user's time online may be adjusted to ensure the event occurs on time - by placing a $ (dollar sign) as the first character of the name. The CONFIG.EXE compiler will automatically strip this character for you. NanoBBS events have a unique feature: you can have up to 32 unique times at which each event can execute. Unlike most other BBSes, you can specify more than one time of day for each event to occur, and you can even have the same event occur several times in the same day if you desire! These are just examples; you should adjust the times, days, names and errorlevels to suit your system best. See the chapter titled "The Black Art of Batch File Writing" for examples of how to use the errorlevels. Here are two nice normal events which occur once per night at the same time. The first event is forced; a user online will have her time limit adjusted if the call is close enough to midnight! event 1 All 00:00 100 $Midnight Door Updates event 2 All 04:00 110 Nightly Maintenance Here is an event which occurs at 4:30am Thursday and 5:00am Sunday. Note that on the second line the errorlevel and name are not needed. event 3 Thu 04:30 120 Semi-Weekly Maintenance event 3 Sun 05:00 This event runs three times a day at 2:00am, 10:00am and 6:00pm. event 4 All 02:00 130 Galactic Empire Update (Thrice Daily!) event 4 All 10:00 event 4 All 18:00 NanoBBS 1.16 Documentation Page 31 ┌─────────────────────────────────────────────────────────────┐ │ OTHER KEYWORDS │ └─────────────────────────────────────────────────────────────┘ If uncommented, the EMAILSCAN GLOBAL option will cause NanoBBS to search all the areas the user has defined for global scans when checking for new email at each logon. By default (commented out) NanoBBS will only scan the defined private email base for new personal mail. emailscan global NanoBBS 1.16 Documentation Page 32 ╔═╦══════════════════════════╦═╗ ║ ║ Setting Up Message Areas ║ ║ ╚═╩══════════════════════════╩═╝ Message areas are defined in the MSGAREA.CTL file. Like the system configuration file in the previous chapter, this is a flat ASCII file which can be edited with any ASCII text processor. Once you have edited MSGAREA.CTL to your needs, you must then compile the message base configuration file into the MSGAREA.DAT file which NanoBBS can more easily read. This can be done in two ways. The simplest is to run the CONFIG program as you did for the NODE1.CTL general config file. Tbis will also compile the MSGAREA.CTL file. The other way is to run the MMB.EXE program like so: MMB MSGAREA This compiles your MSGAREA.CTL into MSGAREA.DAT the same way that CONFIG.EXE did, because CONFIG actually calls MMB.EXE in the process of configuring everything. However this way will only compile the message areas; file areas, doors and general configuration remain unaffected when you use MMB. Each message area is defined by a set of lines in the MSGAREA.CTL file. The first line of each area's definition starts with MSGAREA and the area's number, and ends with END. ┌─────────────────┐ │ A basic example │ └─────────────────┘ msgarea 1 name Ye Public Roaste type squish public access 10 path c:\bbs\msg\public end In the above example, we are defining Message Area 1 (hence the first line). Its name is "Ye Public Roaste", as defined by the NAME command. It is a Squish type message base, as defined by the TYPE command. It is a public message area, as defined by the existence of the PUBLIC command. This means that private messages are not possible in the area. The minimum access needed to use this area is 10, as defined by the ACCESS command. NanoBBS 1.16 Documentation Page 33 The messages themselves are stored in the directory C:\BBS\MSG\, and the base filename of the Squish files for this base is PUBLIC. This is defined by the PATH command. It is worth noting that in a Squish or JAM base, the base filename is included in the path. That means that if the PATH is C:\BBS\MSG\PUBLIC and this is a Squish area, NanoBBS will use the following files: C:\BBS\MSG\PUBLIC.SQI C:\BBS\MSG\PUBLIC.SQD C:\BBS\MSG\PUBLIC.SQL and C:\BBS\MSG\PUBLIC.SQB A similar mechanism is used to define the base filename for JAM message areas. However, for *.MSG areas this defines the full directory name where all of the message files live. In *.MSG there is one file for every message, plus several auxiliary files (most notably the LASTREAD file) so each *.MSG area must be in its own directory to avoid a serious and acute crosslinking problem! ┌───────────────────────────────┐ │ A real-world Echomail example │ └───────────────────────────────┘ msgarea 5 name Chatter Echo type JAM path c:\bbs\msg\chatter access 10 postaccess 15 realname echomail address 1:340/26 Origin NanoBBS in '95! 604-361-4549 public qwkname Chatter barricade censor end This is message area 5, named "Chatter Echo". It is a JAM type area which lives in C:\BBS\MSG\ and its files start with the base filename CHATTER. Users need access level 10 to use the message area but only users with access level 15 can post messages there. This area will use the user's "Real Name" instead of the "User Name". It is an echomail area - perhaps this is why you would want to force the use of a real name. The Fidonet address used in the Origin line and elsewhere in the message is 1:340/26. The origin line itself will read: * Origin: NanoBBS in '95! 604-361-4549 (1:340/26) This is a "Public" area, and it is subject to the Barricade file (see the section on miscellaneous external files). When the user downloads messages from this area into a QWK packet, the NanoBBS 1.16 Documentation Page 34 BBS will associate the name "Chatter" with the area in the QWK packet. And, the Message Censor will be applied to all messages posted by your users in this area. ┌────────────────────────┐ │ An example of a │ │ specialty message area │ └────────────────────────┘ msgarea 49 name Adult Network Ladies Only Base path c:\bbs\msg\ladies access 20 postaccess 20 age 21 type Squish public femaleonly qwkname LadiesOnly end This is Message Area 49, which as you can see is open only to women over 21 - and the BBS will enforce this for you! Most BBSes do not have this possibility. ┌──────────────────────────────────────────────────────────┐ │ │ │ There are several more examples in the MESSAGES.CTL file │ │ that comes with NanoBBS. │ │ │ └──────────────────────────────────────────────────────────┘ ──────────────────────────────────────────────────────────── ┌────────────────────────────────────┐ │ A complete listing of all of the │ │ available keywords for MSGAREA.CTL │ └────────────────────────────────────┘ INCLUDE {filename}- This tells MMB to open the specified filename and take its input from that file - or in other words, "include" it. MSGAREA {number} - Starts a message area definition. Every message area starts with this. MSGAREA @NEXT - Starts a message area definition, gives the new area an area number one higher than the last one. Use this instead of an area number to auto-number your message areas (this makes inserting new ones in the middle a breeze!) MSGAREA @NEXT 10 - Starts a message area definition, gives the new area an area number 10 higher than the last one. You can specify any number here. NanoBBS 1.16 Documentation Page 35 NAME {Area Name} - Defines the message area's name as the user sees it. This can be up to 60 characters long, and it may contain embedded colours! QWKNAME {Name} - Defines the area name as it is seen in the user's QWK reader. Due to a limitation of the .QWK standard, the QWKNAME must be 12 characters or less. This in fact is the main reason why NanoBBS lets you define this name separately. NEWSGROUP {news.group} - Defines the Usenet Newsgroup (if any) associated with this message area. This is just a usenet newsgroup name in a format like: comp.bbs.nanobbs This can be up to 80 characters in size. TYPE {type} - Defines the message base type, either SQUISH, JAM or *.MSG. Squish and JAM are the recommended types, with *.MSG included for completeness and backward compatibility. PATH {path} - Defines what directory the area lives in. For Squish and JAM areas this also includes the base filename. If this is a *.MSG area, the .MSG and other files are in this directory. ATTACH PATH {path} - This defines the path where file attaches in this area will be stored. If this path is not defined, file attaches will not be allowed. File attaches are an advanced feature that lets users send each other files via your system. ATTACH ACCESS {ac} - This defines the access level needed to post file attaches to this area. If the user doesn't have this access level or higher, s/he is never even asked if a file attach is wanted. This option has no effect unless the ATTACH PATH is also defined. ACCESS {access} - Defines the access needed to read messages. POSTACCESS {ac.} - Defines the access needed to post messages. PRIVATE - Only private messages are allowed. PUBLIC - Only public messages are allowed. If neither this nor PRIVATE is used, the user is asked if the message should be private. RFC1036 - This causes an RFC-1036 Usenet message header to be prepended to the message text. This is used in conjunction with external Usenet processors. AGE {age} - Minimum age required for access to the area FEMALEONLY - Only females may read or post to the area. MALEONLY - Only males may read or post to the area. NanoBBS 1.16 Documentation Page 36 READONLY - This is a read-only area - only the sysop can post! This may be somewhat redundant as it has the same effect as setting POSTACCESS to the sysop access level. This is useful for setting up an announcements area or a file-distribution area (using file attaches). ECHOMAIL - This command simply indicates that this is a Fidonet echomail area, so that NanoBBS will attach the necessary Echomail information to the message when it is saved. NETMAIL - This command simply indicates that this is a Fidonet netmail area, so that NanoBBS will attach the necessary Netmail information to the message when it is saved. ADDRESS {z:n/n.p}- The originating Fidonet type address for this area. This is needed for all Echomail and Netmail areas. This is in the standard 4D format, examples: 1:340/26 69:3601/1 89:688/13.2 64:819/17.12 ORIGIN {OrgLine} - The text of the Origin Line for this area KLUDGE REALNAME - The user's real name will be hidden in a ^A kludge line prepended to the message text. INTERNET EMAIL - The area is intended for Internet email. INTERNET DIVERT {area} - If the user enters a To: that appears to be intended for an Internet address (the presence of @, period or exclamation point will trigger this), then NanoBBS will divert the message to the specified area number - if the user has access! KEYS {keys} - The user key(s) required for access POSTKEYS {keys} - The user key(s) required to post messages REALNAME - Always post with the user's real name ANONYMOUS - Allow anonymous posting CENSOR - Use the built-in message censor in this area. BARRICADE - This will enable a check of the barricade file MESSAGES.BAR before changing to this area. If the user is barricaded from this area, this must be active in order for the barricade to work! END - End the area's definition. NanoBBS 1.16 Documentation Page 37 You may also demarcate message areas by content type, network affiliation or whatever criterion you like by grouping them together and partitioning them with dividers. A divider is just a "break" in the area list. You can put a divider anywhere between area definitions in the MSGAREA.CTL file. DIVIDER - Start a divider definition (no parameters) DISPLAY - Text to display in the divider (see SysMsg 340 in the language file) FILENAME {name} - Display filename specified by {name} instead of SysMsg 340 MALEONLY FEMALEONLY AGE {age} ACCESS {access} KEYS {keys} - AGE, ACCESS, KEYS, MALEONLY and FEMALEONLY enable or suppress the divider in much the same way they do for message area definitions END - End the divider's definition ╔═╦═══════════════════════╦═╗ ║ ║ Setting Up File Areas ║ ║ ╚═╩═══════════════════════╩═╝ File areas are defined in the FILEAREA.CTL file. Like the system configuration file and message area configuration file in the previous chapters, this is a flat ASCII file which can be edited with any ASCII text processor. Once you have edited FILEAREA.CTL to your needs, you must then compile the file area configuration file into the FILEAREA.DAT file which NanoBBS can more easily read. This can be done in two ways. The simplest is to run the CONFIG program as you did for the NODE1.CTL general config file. Tbis will also compile the FILEAREA.CTL file. The other way is to run the MFB.EXE program like so: MFB FILEAREA This compiles your FILEAREA.CTL into FILEAREA.DAT the same way that CONFIG.EXE did, because CONFIG actually calls MFB.EXE in the process of configuring everything. However this way will only compile the file areas; message areas, doors and general configuration remain unaffected when you use MFB. Each file area is defined by a set of lines in the FILEAREA.CTL file. The first line of each area's definition starts with FILEAREA and the area's number, and ends with END. NanoBBS 1.16 Documentation Page 38 ┌─────────────────┐ │ A basic example │ └─────────────────┘ FileArea 1 access 10 name General Upload Files Download c:\file\upload\ Upload c:\file\upload\ end In this example, we are defining file area 1. Its name is "General Upload Files" and the user must have access level 10 or above to use the area. The FILES.BBS file and the actual files are in the C:\FILE\UPLOAD\ directory, and that is also where uploads are saved. There is otherwise nothing special about this area. ┌──────────────────────────────────┐ │ A slightly more involved example │ └──────────────────────────────────┘ FileArea 3 access 20 name Naughty Adult Pictures download c:\bbs\files\adult\ upload c:\bbs\files\screen\ age 21 end Note that in this example the DOWNLOAD and UPLOAD directories are different. The files and the FILES.BBS file are in C:\BBS\FILES\ADULT\, but uploaded files are saved in C:\BBS\FILES\SCREEN\. When a user uploads a file to this area, not only does the file end up in the UPLOAD directory, but any description the user enters for the file goes in a FILES.BBS located in the UPLOAD directory. Also in this example, a lower age limit of 21 years is specified, and an access level of 20 is required. ┌───────────────────────┐ │ Defining CD-ROM areas │ └───────────────────────┘ filearea 2001 name Alt Operating Sys. upload c:\file\upload\ download g:\001a\ access 10 cdrom filesbbspath c:\cdrom\001a\ end In this example, area 2001 is on a CD. Note that there are three different paths. The DOWNLOAD path is the actual directory on the CD where the files reside. The UPLOAD path is NanoBBS 1.16 Documentation Page 39 where uploads go. Of course, CD-ROMs are not writeable, so it is very important that you specify an upload path that is on a writeable disk! The third path, FILESBBSPATH, is the location of the FILES.BBS file. This is where the file names and descriptions are kept. This feature is useful for allowing you to "remove" files from CD directories that you don't want users to access, or to allow you to change the description of a file on a CD. An alternative for CD-ROM areas is to use the NOUPLOADS keyword. Instead of shuttling uploads to some other directory, NOUPLOADS will actually refuse to accept an upload if the user is in a file area that has this keyword. I think that it is much more user-friendly to allow users to upload regardless of the area they're logged to, using the UPLOADPATH keyword. Note the use of the CDROM keyword. This instructs NanoBBS to first copy the requested file or files from the CD to a temporary directory (the one specified in your general config file) before downloading. The files are then downloaded from the hard disk - or RAMdisk if you're fortunate enough to have one large enough to practically handle this job. This greatly reduces the overhead caused by CD-ROM accesses. ┌────────────────────────────────────────────────────────────┐ │ Note to LAN users: If you are using a slow LAN (2 MBPS or │ │ less) you may want to consider using the CDROM keyword for │ │ any areas that live across the LAN from the machine the │ │ user logs onto, even if they're on a hard disk. This can │ │ cut down on LAN overhead quite a bit. │ │ └────────────────────────────────────────────────────────────┘ The best way to deal with a CD that already has FILES.BBS files is to simply make a mirror of the CD's directory tree on your hard disk. Then copy all the FILES.BBS files to the hard disk mirror and set the FILESBBSPATH for each area on the CD to the relevant mirror directory. Making a mirror directory is easy. ALl you need to do is (something like) this: C:\> xcopy g:\files.bbs c:\cdrom\ /s /e ... in this simple DOS example, we're asking XCOPY to make copies on the hard disk of all the FILES.BBS files on the CD, creating the directories as needed, and in fact building an empty copy of the whole directory tree. For most CDs the hard disk usage by this technique should be negligible. NanoBBS 1.16 Documentation Page 40 ┌─────────────────────────────────────┐ │ A complete listing of all of the │ │ available keywords for FILEAREA.CTL │ └─────────────────────────────────────┘ INCLUDE {filename}- This tells MFB to open the specified filename and take its input from that file - or in other words, "include" it. This is useful for rotating CD-ROMs where you have several CDs defined but only one drive: you could rotate them by simply commenting out the include name for the outgoing CD, uncomment the include for the incoming CD, and then just swap the CDs themselves. Voila! FILEAREA {number} - Starts a file area definition. NAME {Area Name } - Defines the file area's name DOWNLOAD {path} - Defines where the files themselves exist UPLOAD {path} - Defines where files should be uploaded FILESBBS {path} - Defines where the FILES.BBS file lives. This is optional; if it is not used FILES.BBS will be expected in the same directory as DOWNLOAD. AGE {age} - The minimum age needed to access the area CDROM - This means the area is on a CD. Files are copied to a temporary directory prior to downloading. ACCESS {access} - Defines the access needed to use the area. ULACCESS {access} - Defines the access needed to upload in the area. DLACCESS {access} - Defines the access needed to download in the area. KEYS {keys} - Defines the key(s) needed to use the area. ULKEYS {keys} - Defines the key(s) needed to upload in the area. DLKEYS {keys} - Defines the key(s) needed to download in the area. NOUPLOADS - Uploading is not allowed in the area. PCBSTYLE - This indicates that the FILES.BBS file in this area includes the file date and size (regular FILES.BBS files do not). Since NanoBBS already displays this information, this keyword causes NanoBBS to strip the redundant information from the FILES.BBS when it is displayed. This keyword gets its name from the fact that the extra information stripped by this keyword is the only important difference between FILES.BBS and the PC-Board DIR* files - thus you can use the DIR files found on some CD-ROMs with little or no modification. NanoBBS 1.16 Documentation Page 41 INDENTDESC - Some CD-ROMs use a slightly different way of indicating a continued long file description - they indent the continued description several columns rather than using a special character as NanoBBS does. By using this keyword, such FILES.BBS files can be used unmodified and will have properly wrapped descriptions. Do not use this keyword indiscriminately - it can cause problems with indented comment lines! END - End the area's definition. ╔═╦══════════════════════════╦═╗ ║ ║ Setting Up Doors ║ ║ ╚═╩══════════════════════════╩═╝ "Doors" are external programs, usually games, that can be called up by the BBS for users to use while they are online. Whirlwind Software's Rancho Nevada, Galactic Empire, The Streets, S.T.U.P.I.D., and others, are examples of popular door programs compatible with NanoBBS and many other BBSes. Having only been sysoping for the last seven years or so, I can't claim to be an authority on this, but I believe the term "Door" originated on BBSes that were arranged to be like buildings in a text adventure game. The "Door" was a doorway out of the BBS and into another game altogether. Please don't flame me if I'm out to lunch on this. Doors are defined in the DOORS.CTL file. Like the system configuration file and message area/file area configuration files in the previous chapters, this is a flat ASCII file which can be edited with any ASCII text processor. Once you have edited DOORS.CTL to your needs, you must then compile the doors configuration file into the DOORS.DAT file which NanoBBS can more easily read. This can be done in two ways. The simplest is to run the CONFIG program as you did for the NODE1.CTL general config file. Tbis will also compile the DOORS.CTL file. The other way is to run the MAKEDOOR.EXE program like so: MAKEDOOR {filename} ...where {filename} is the file name of the doors file you want to compile. It is usually DOORS.CTL. This compiles your DOORS.CTL into DOORS.DAT the same way that CONFIG.EXE did, because CONFIG actually calls MAKEDOOR.EXE in the process of configuring everything. However this way will only compile the doors configuration; file areas, message areas and general configuration remain unaffected when you use MAKEDOOR. Each door is defined by a set of lines in the DOORS.CTL file. The first line of each door's definition starts with DOOR and the door's number, and ends with END. NanoBBS 1.16 Documentation Page 42 Here is a basic example: door 1 path c:\doors\rancho\ command rancho.exe -l -a flavour dorinfo1.def access 50 realname end The preceding example calls Rancho Nevada. It logs to the directory C:\DOORS\RANCHO\, and calls RANCHO.EXE with the -l -a command line parameters. It requires an access level of 50 to access, uses a DORINFO1.DEF door info drop file, and will substitute the user's real name for the username. door 2 path c:\doors\hiq\ command %C /C hiq.bat flavour dorinfo1.def access 10 lastname NLN end This example calls Hi-Q. It logs to the C:\DOORS\HIQ\ directory and calls up COMMAND.COM, which in turn calls up HIQ.BAT. We assume in this example that there is already a HIQ.BAT in place which takes the appropriate steps to run Hi-Q. Access level 10 is needed, and if the user is using a one-word pseudo, the last name NLN will be forced. ┌────────────────────────────┐ │ A Complete Listing of │ │ All the Keywords Available │ │ for DOORS.CTL │ └────────────────────────────┘ PATH specifies the path where NanoBBS should change to before running the door. COMMAND specifies the executable filename and command line parameters needed to run the door. Use %c /c to specify a fully pathed COMMAND.COM for running batch files. In the COMMAND parameter, you can substitute %n for the node number, %c for the COMMAND.COM comspec (which you need to execute batch files). These will be translated into their full form when the door is run, e.g. if the user is on node 10, %n is translated automatically into 10. If you're running 4DOS, %c might translate into C:\4DOS\4DOS.COM. Under plain vanilla DOS, %c would likely translate into C:\COMMAND.COM or perhaps C:\DOS\COMMAND.COM. Note that to run a batch file, you MUST include the /C command line switch after the COMMAND.COM (or %c) and before the batch file name. NanoBBS 1.16 Documentation Page 43 FLAVOUR can be either DORINFO1.DEF, DORINFOX.DEF or DOOR.SYS. DORINFOX.DEF is a special "flavour" where the node number is built into the filename, e.g. DORINFO2.DEF, DORINF25.DEF, DORIN132.DEF etc. AGE is the minimum age a user has to be to use the door. ACCESS is the minimum access level a user must have to use the door REALNAME tells NanoBBS to use the real name instead of the user name LASTNAME tells NanoBBS what to put in for a last name if the user has a one-word handle. If this statement is missing, the last name is left blank. NanoBBS 1.16 Documentation Page 44 ┌─┬─┬─┬─┬─┬─────────────────────────────────────┬─┬─┬─┬─┬─┐ │ │ │ │ │ │ THE BLACK ART of BATCH FILE WRITING │ │ │ │ │ │ └─┴─┴─┴─┴─┴─────────────────────────────────────┴─┴─┴─┴─┴─┘ The Basics - Why Batch files? Batch files are an important part of any true DOS BBS, whether it be NanoBBS, Maximus, RemoteAccess, Opus, or any one of dozens of others on the market today. Once you're inside the BBS, NanoBBS takes care of itself for you, but how you enter the BBS is under the control of your DOS batch files. There are several ways in which you can enter NanoBBS. - You can just type BBS at the prompt. Assuming everything's OK configuration-wise, NanoBBS will assume you're in local mode and will present you with the logon prompt. You may have to hit [Enter] first depending on your choice for that option. You can then log on, do your thing and log off, all the time never even looking at the modem. And once you're done, you're back at the DOS prompt where you started. - You can put NanoBBS into its Wait-For-a-Call (WFC) mode. This is achieved simply by typing BBS /W at the DOS prompt. NanoBBS will enter its WFC mode and will wait for one of the following: o An incoming modem call o An event o A local logon (using Alt-L) o An ESC key from the keyboard, indicating that it's time to exit. After any of the above are completed, NanoBBS exits back to DOS. - You can start up NanoBBS "Hot" from a mailer or as a sort of door. This is done by specifying a baud rate with the /B command line switch. When this switch is used, NanoBBS assumes that the modem is active and that a connection has already been made, and it begins an online session at the specified baud rate. Once the session is finished, NanoBBS exits back to DOS. All of these methods basically call up NanoBBS once, run through a single online (or local) session, and then exit back to DOS. Of course, you want to be able to handle many calls in a row, so just using these methods by themselves isn't practical. This is where the batch files come in. In an unattended BBS you need the BBS to go back to a Fidonet mailer or go back to waiting for a call after an online session is complete. This is done with batch files. NanoBBS 1.16 Documentation Page 45 ┌─────────────────────────┐ │ The Simplest Batch File │ └─────────────────────────┘ Here is the simplest possible example of an unattended BBS batch file. It makes some assumptions. BBS /W RUNBBS.BAT Firstly, it assumes that its own name is RUNBBS.BAT. The second line re-cycles the batch file by non-recursively calling itself. It also assumes that your BBS.EXE is on the DOS path (see your PATH statement in AUTOEXEC.BAT). The problem with this batch file is that there's no way to get out of it unless you're REALLY quick with the Ctrl-Break key! It doesn't check to see if you had hit [Esc] to exit WFC (Waiting For Caller), nor does it try to process events. All it can do is keep fielding calls. This problem is overcome with... ┌─────────────────────┐ │ NanoBBS Errorlevels │ └─────────────────────┘ DOS provides a way for programs to communicate with DOS after the program has finished. This is called an ERRORLEVEL. What this is, is a number that the program passes back to DOS on completion, which is supposed to be a "what went wrong" code. NanoBBS doesn't use errorlevels the way the DOS programmers had in mind. Instead, it uses the errorlevel to tell your batch file how the program finished: Did it exit normally? Did the SysOp hit the Escape key? Is an event being run? NanoBBS has two hardcoded errorlevels, and lets you define errorlevels for your events. They are: SysOp hit ESCAPE at the WFC screen : Errorlevel 1 BBS Exited normally after an online or local session : Errorlevel 0 An Event is being run : Errorlevel 2 thru 255 NanoBBS 1.16 Documentation Page 46 Let's translate this into another example, this one of a much more practical (but still very simple) batch file: @ECHO OFF :TOP C: CD\BBS BBS /W IF ERRORLEVEL 2 GOTO TOP IF ERRORLEVEL 1 GOTO FINISH GOTO TOP :FINISH @ECHO BBS OFFLINE! This example uses two of DOS's batch file commands. They are the GOTO command and the IF ERRORLEVEL command. Let's look at this example line by line. @ECHO OFF This just turns off DOS echoing, so that the appearance is neater when the batch file runs. :TOP This is a "label" declaration. Later in the batch file there is a GOTO TOP command. It will cause the batch file to go to this line and continue running from here. C: CD\BBS These lines just make sure that DOS is logged to the right directory. It is possible for doors and external programs to change the current directory while the online BBS session is running, so we include these two lines to set right any such discrepancy. Of course this is only an example; if you run your BBS in a directory other than C:\BBS\, you must change these lines to suit your paths. BBS /W This calls NanoBBS in WFC (Waiting For Call) mode. When NanoBBS is finished it will present a DOS errorlevel which can be checked by the following two lines: IF ERRORLEVEL 2 GOTO TOP This checks the DOS errorlevel. The errorlevel might be anywhere from 0 to 255. However, all the errorlevels above 1 are reserved for the events, so in this batch file we need only be concerned with errorlevels 0 and 1. What this line does is check to see if any errorlevel ABOVE 1 (meaning from 2 to 255 inclusively) is there. If so, it uses the GOTO TOP part to "go" to the :TOP label above. In this batch file, that means it will "loop" and call the BBS again. If the errorlevel is below 2, the batch file simply goes to the next line... IF ERRORLEVEL 1 GOTO FINISH This is similar to the above line. Technically, this checks to NanoBBS 1.16 Documentation Page 47 see if the errorlevel is 1 or higher, but since the above line would've transferred control to the :TOP label, this line can really only do the GOTO FINISH if the errorlevel is exactly 1. Note that Errorlevel 1 is returned when you escape from WFC modem by hitting escape. This line, then, breaks out of the "loop" formed by the batch file. If you hit Escape at WFC, you'll get the DOS prompt back. If NanoBBS exits for any other reason, it re-cycles - and calls itself again. GOTO TOP This "goes" back to the :TOP label. Because the above IF ERRORLEVEL lines have checked all other errorlevels, this line can only be reached if the errorlevel is zero. Errorlevel 0 is returned after an online session, so we want to "loop" back to the :TOP label. :FINISH This label indicates where the batch file should "GOTO" when you exit NanoBBS by hitting Escape at the WFC (Wait for Call) screen. See the IF ERRORLEVEL 1 GOTO FINISH line a couple of lines up. @ECHO BBS OFFLINE! This is just a cosmetic line to indicate that the batch file has terminated normally. If this example is run as shown, you should only see this if you actually hit Escape at the WFC screen. ┌────────────────────────────────────────────────────────────────┐ │ IMPORTANT NOTE ABOUT ERRORLEVELS: │ │ │ │ Many DOS commands will change or clear the value of DOS's │ │ errorlevel variable. For this reason, you MUST place your IF │ │ ERRORLEVEL checks immediately after the BBS call in the batch │ │ file. If any DOS commands or other programs are used after │ │ the BBS, they may change the errorlevel and the result is that │ │ the series of IF ERRORLEVEL statements will be invalid, and │ │ your batch file will not work properly. │ └────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────────────┐ │ Using The Errorlevels Passed By Events │ └────────────────────────────────────────┘ Now that we have established the basic use of errorlevels, let us examine a more advanced example, which processes events. Here are the event examples in NODE1.CTL: event 1 All 00:00 100 $Midnight Door Updates event 2 All 04:00 110 Nightly Maintenance event 3 Thu 04:30 120 Semi-Weekly Maintenance event 3 Sun 05:00 event 4 All 02:00 130 Galactic Empire Update (Thrice Daily!) event 4 All 10:00 event 4 All 18:00 NanoBBS 1.16 Documentation Page 48 So we have four events, and therefore four event errorlevels. Let's have a look at a batch file that would process these errorlevels. I have included line numbers in {curly brackets}. You wouldn't actually use these line numbers in a real batch file... @ECHO OFF {1} {2} :TOP {3} C: {4} CD\BBS {5} BBS /W {6} IF ERRORLEVEL 131 GOTO TOP {7} IF ERRORLEVEL 130 GOTO GALACTIC {8} IF ERRORLEVEL 120 GOTO SEMIWEEKLY {9} IF ERRORLEVEL 110 GOTO NIGHTLY {10} IF ERRORLEVEL 100 GOTO MIDNIGHT {11} IF ERRORLEVEL 1 GOTO FINISH {12} GOTO TOP {13} {14} :GALACTIC {15} C: {16} CD\DOORS\GALACTIC {17} G.EXE /M {18} GOTO TOP {19} {20} :SEMIWEEKLY {21} C: {22} CD \ECHOMAIL {23} SQPACK *.SQD {24} CD \ {25} VOPT {26} GOTO TOP {27} {28} :NIGHTLY {29} C: {30} CD \ {31} SCAN C: D: E: F: {32} GOTO TOP {33} {34} :MIDNIGHT {35} C: {36} CD \BBS {37} BBS /F {38} GOTO TOP {39} {40} :FINISH {41} @ECHO BBS OFFLINE! {42} If you're new at this, this example may seem a bit complex and overwhelming! But in reality, many BBS batch files are even more complicated than this. And really, if you break it down, it's not so difficult. This batch file is basically similar to the previous example. The first six lines are the same, establishing the :TOP label NanoBBS 1.16 Documentation Page 49 and calling the BBS in WFC mode. Lines 7 through 13 handle the errorlevels. In line 7, any errorlevel above 130 (the highest errorlevel defined in the EVENT statements) causes the batch file to loop back to :TOP. In line 8, the batch file checks for errorlevel 130. If the errorlevel is exactly 130, the batch file transfers to the :GALACTIC label. In line 9, if the errorlevel is 120, the batch file goes to the :SEMIWEEKLY label. In line 10, if the errorlevel is 110, the batch file goes to the :NIGHTLY label. In line 11, if the errorlevel is 100, the batch file goes to the :MIDNIGHT label. Line 12 should loo familiar. It checks for errorlevel 1, which is returned when you hit Escape in the WFC screen. If the errorlevel is 1, the batch file exits. Line 13 simply loops back to the :TOP label. Lines 15 through 19 make up what happens when the errorlevel from BBS.EXE is 130. In line 8, if the errorlevel is 130 the batch file branches to the :GALACTIC label, on line 15. Here, several DOS commands change the directory to C:\DOORS\GALACTIC and run G.EXE. After this is done, the GOTO TOP returns to the :TOP label, to await another call. Similar groups of lines, starting with a label and ending with GOTO TOP, make up the commands that are called for each errorlevel. Finally, at line 41, we have the :FINISH label, and the way out. ┌─────────────────────────────────────┐ │ Using batch files with Fido mailers │ └─────────────────────────────────────┘ One important thing that the above examples have in common is that they are all meant for stand-alone BBSes - BBSes which answer the phone themselves and don't have to use a mailer program like Binkleyterm or Frontdoor. However, when you use a mailer, the batch mechanism is usually quite different. Different mailers have different ways of passing off information such as baud rate, time remaining, etc. to the BBS. Generally, your batch file calls up the mailer instead of the BBS, and looks for the mailer's errorlevels instead of your BBS's errorlevels. NanoBBS 1.16 Documentation Page 50 Here is an example batch file called RUN.BAT which works with BinkleyTerm. @echo off :top c: cd\bink bt if errorlevel 144 bbsbatch.bat if errorlevel 120 bbsbatch.bat if errorlevel 100 goto mail if errorlevel 96 bbsbatch.bat if errorlevel 79 goto domaint if errorlevel 72 bbsbatch.bat if errorlevel 48 bbsbatch.bat if errorlevel 24 bbsbatch.bat if errorlevel 12 bbsbatch.bat if errorlevel 3 bbsbatch.bat if errorlevel 1 goto done goto top :domaint @echo *** Now Doing Daily Maintenance call c:\flit\filelist.bat call c:\batch\msgmaint.bat goto top :mail c: cd\squish squish in out squash goto top :done In the example on the previous page, we check for errorlevels passed by BinkleyTerm. One of BinkleyTerm's features is that when there is a BBS connect (that is, when the user hits Escape upon connection to BinkleyTerm) Binkley exits with an errorlevel which is based on the connect baud rate. This errorlevel is the baud rate divided by 100, e.g. errorlevel 24 for 2400 baud, errorlevel 96 for 9600 baud, etc. NanoBBS 1.16 Documentation Page 51 ┌───────────────────────────────────────────────────────────────┐ │ Aside: │ │ │ │ Remember I mentioned that errorlevels can be from 0 to 255? │ │ This is true, but it's not a problem to pass, or check for, │ │ an errorlevel above 255. What happens is that the errorlevel │ │ is "rolled over" so that it is less than 255. In technical │ │ terms, the errorlevel is handled by DOS as if it were modulo │ │ 256, or the remainder of the actual errorlevel divided by 256.│ │ │ │ So, if you have a V.34 modem, Binkley may try to pass │ │ errorlevel 288 - for 28800 baud. This is fine, and you can │ │ legally use a statement like IF ERRORLEVEL 288 with no │ │ problems but be cautioned that errorlevel 288 is the same as │ │ errorlevel 32 as far as DOS is concerned! 288 modulo 256 is │ │ 32. So if you wanted to use errorlevel 32 for something else,│ │ you would run into a conflict here. │ │ │ │ As long as you are aware of this potential conflict, you can │ │ write your batch file so as to avoid it. │ └───────────────────────────────────────────────────────────────┘ In the above example, we start off by changing to the BinkleyTerm directory and running BT.EXE. After that, the IF ERRORLEVEL statements check for numerous errorlevels. Binkley generates a different errorlevel for each baud rate and this batch file checks for errorlevels 144, 120, 96, 72, 48, 24, 12 and 3. Since all of these errorlevels indicate a BBS session rather than a BinkleyTerm event, they all cause the same thing to occur: a batch file called BBSBATCH.BAT is called. We'll look at BBSBATCH.BAT momentarily; it is a very important part of this method. The other errorlevels have various functions. Errorlevel 100 causes a jump to the :MAIL label, where several DOS commands pack and unpack echomail using Lanius' SquishMail system. Errorlevel 79 jumps to the :DOMAINT label, which in turn calls a couple of other batch files (using the dos CALL command) which might in turn call numerous daily maintenance routines. In both cases, the batch file returns to :TOP to call up Binkley again. BinkleyTerm generates a one line batch file called BBSBATCH.BAT. This is called by the batch file above, and it looks something like this: SPAWNBBS 14400 14400 1 46 /Arq But what is SPAWNBBS, you may ask? If you guessed it's another batch file, you're right! You may be thinking that this is getting unnecessarily complicated, but this actually gives the mailer incredible flexibility in dealing with different BBSes. Before we look at SPAWNBBS.BAT, let's examine the above one-liner. The first 14400 is the baud rate. We can pass this on to NanoBBS using the /B switch, and in fact we must in order NanoBBS 1.16 Documentation Page 52 for it to work from a mailer. We can ignore the second 14400 for now. The third parameter, 1, is the com port. NanoBBS gets its com port information from its config file so this is not needed either. After that is the time left until the next mailer event, in minutes. This can be passed to NanoBBS using the /T command line switch, so that NanoBBS enforces your mailer's events for you. The last parameter is the connect information passed back by the modem, e.g. CONNECT 14400/ARQ would produce the /Arq shown above. Unfortunately, Binkley is fixed in the format of this batch file, so we need a third batch file to translate it into something NanoBBS can be called from. This is where SPAWNBBS.BAT comes in. Here is an example SPAWNBBS.BAT: c: cd\bbs bbs -cnode2 -b%1 -t%4 c: cd\bink run See the parameters in line 3? -cnode2 tells NanoBBS to use NODE2.DAT (which means you have to CONFIG NODE2), and -b%1 means that NanoBBS is to use the %1 DOS variable with the -b (baudrate) switch. And, -t%4 means that NanoBBS is to use the %4 DOS variable with the -t (time left) switch. What does that mean? Well, DOS lets you pass parameters to batch files. Up to 9 of them. So, let's look at BBSBATCH.BAT again and its parameters: %1 %2 %3 %4 %5 ----- ----- - -- ---- SPAWNBBS 14400 14400 1 46 /Arq When we call SPAWNBBS.BAT like this, as this BBSBATCH.BAT does, %1 contains the value 14400. %4 contains the value 46. This means that the line bbs -cnode2 -b%1 -t%4 really means bbs -cnode2 -b14400 -t46 and NanoBBS will run at 14400 bps, on whatever com port is defined in NODE2.CTL, and will impose a 46 minute maximum limit so that the mailer's event can run on time. Note that after the BBS runs, no errorlevel checking is done. This is because NanoBBS events are really only relevant to WFC mode, which is nonexistent when you run NanoBBS this way. Once the BBS has finished running, the SPAWNBBS.BAT logs back to NanoBBS 1.16 Documentation Page 53 the mailer directory and calls up the original RUN.BAT again. Let's break this whole complicated mess down into steps. ┌───────────────────────────────────────┐ │ RUN.BAT - Runs the mailer, and checks │ │ errorlevels for mailer events or BBS ├<───┐ │ callers. │ │ └───────────────────┬───────────────────┘ │ \│/ /│\ ┌───────────────────┴────────────────────┐ │ │ Mailer generates one-line BBSBATCH.BAT │ │ └───────────────────┬────────────────────┘ │ \│/ │ ┌────────────────┴────────────────┐ │ │ BBSBATCH.BAT calls SPAWNBBS.BAT │ /│\ └────────────────┬────────────────┘ │ \│/ │ ┌──────────────────┴─────────────────────┐ │ │ SPAWNBBS.BAT takes the %1 and %4 batch │ │ │ variables and passes them to NanoBBS. │ │ └──────────────────┬─────────────────────┘ │ \│/ /│\ ┌──────────────────┴─────────────────────┐ │ │ Once NanoBBS is finished, SPAWNBBS.BAT │ │ │ returns to the RUN.BAT batch file. ├──┘ └────────────────────────────────────────┘ Here is another example of a batch file that works with Binkleyterm, but it can do the whole thing in one batch file, without needing the SPAWNBBS.BAT file or Binkley's BBSBATCH.BAT file. It is slightly less sophisticated in that it is oblivious to Binkley's events and will not try to force them. If you must force BinkleyTerm events, don't write your batch file this way... @echo off :top c: cd\bink bt if errorlevel 144 goto bbs14400 if errorlevel 120 goto bbs12000 if errorlevel 100 goto mail if errorlevel 96 goto bbs9600 if errorlevel 79 goto domaint if errorlevel 72 goto bbs7200 if errorlevel 48 goto bbs4800 if errorlevel 24 goto bbs2400 if errorlevel 12 goto bbs1200 if errorlevel 3 goto bbs300 if errorlevel 1 goto done goto top :bbs14400 (continued next page) NanoBBS 1.16 Documentation Page 54 (continuing from previous page) c: cd\bbs bbs.exe -cnode1 -b14400 goto top :bbs12000 c: cd\bbs bbs.exe -cnode1 -b12000 goto top :bbs9600 c: cd\bbs bbs.exe -cnode1 -b9600 goto top :bbs7200 c: cd\bbs bbs.exe -cnode1 -b7200 goto top :bbs4800 c: cd\bbs bbs.exe -cnode1 -b4800 goto top :bbs2400 c: cd\bbs bbs.exe -cnode1 -b2400 goto top :bbs1200 c: cd\bbs bbs.exe -cnode1 -b1200 goto top :bbs300 c: cd\bbs bbs.exe -cnode1 -b300 goto top :domaint @echo *** Now Doing Daily Maintenance call c:\flit\filelist.bat call c:\batch\msgmaint.bat goto top :mail c: cd\squish squish in out squash goto top :done NanoBBS 1.16 Documentation Page 55 See what the preceding batch file does? It actually goes to a different part of the batch file for each baud rate. Thus the BBS is called with the right baud rate based on the errorlevel Binkley passes. ┌──────────────────────────────────────────────────────────────┐ │ Similar batch files are possible with virtually any DOS │ │ mailer you can imagine. In particular, Front Door will work │ │ with the first set of example batch files with only minor │ │ modifications to the batch files. Remember, READ YOUR │ │ MAILER INSTRUCTIONS, particularly the part dealing with │ │ errorlevels and BBS Batch Files, before you write a batch │ │ file you will be relying on! │ │ │ │ And very importantly, TEST your batch files. If you have │ │ more than one line, call your BBS on the other line, at │ │ various baud rates, and just make sure everything's OK. Get │ │ a friend with a mailer to send you netmail. Watch it come │ │ in and make sure it unpacks. You should comment out the │ │ @echo off statements while you're debugging your batch files │ │ so that you can see what's going on. │ │ │ │ Don't be afraid to ask for help from other SysOps! │ └──────────────────────────────────────────────────────────────┘ NanoBBS 1.16 Documentation Page 56 ╔═╦══════════════════════════╦═╗ ║ ║ NanoBBS Utility Programs ║ ║ ╚═╩══════════════════════════╩═╝ CONFIG.EXE - The NanoBBS General Configuration Compiler. See the chapter entitled "The Configuration File" for complete details on the use of this program. MMB.EXE - The NanoBBS Message Base Configuration Compiler MFB.EXE - The NanoBBS File Base Configuration Compiler MAKEDOOR.EXE - The NanoBBS Doors Configuration Compiler ┌─────────┐ │ UFO.EXE │ └─────────┘ UFO.EXE compiles the text source files for UFO scripts into .BBS files which are readable by NanoBBS. Please see the section on UFO commands for more information on the structure and syntax of the source files. UFO.EXE has only one parameter, that is the filename to be compiled. There are no command line switches or other options. If the filename has no path, the current path is assumed. If it has no extension, .UFO is assumed. ┌─────────────┐ │ VIEWUFO.EXE │ └─────────────┘ VIEWUFO.EXE emulates the BBS's UFO syntax parser (in fact it contains a copy of the UFO kernal). It is used for previewing your UFO scripts without having to fire up the BBS and log in, possibly having to wade through many menus to get to the one piece of UFO code you want to test. With VIEWUFO that is not necessary; you can supply the name of any .BBS file on the command line. If no path is given, VIEWUFO first looks in the current directory and then in the "textpath" directory defined in the config control file NODE1.CTL (or whatever you've chosen to name it). The file name is, of course, mandatory but you have another optional parameter: You can emulate the session with any user in your user file by supplying the /U parameter after the filename. The /u should be immediately followed by either the user's number or name if it's a one word pseudo. Examples: VIEWUFO MENU will view a file called MENU.BBS. VIEWUFO MENU /U0 will load the first user record (should be the sysop!!!) and treat all functions with that user's access level, flags and other variables. VIEWUFO MENU /UTommy will load "Tommy" (if present). NanoBBS 1.16 Documentation Page 57 VIEWUFO MENU /UJohn Smith is invalid and will attempt to find a user whose whole name is just "John". I might do something about this in the next version. ┌───────────┐ │ NCOMP.EXE │ └───────────┘ NCOMP.EXE is the NanoBBS language compiler. It is NOT the same as UFO.EXE and its function should not be confused with UFO.EXE. Where UFO compiles scripts which are used to alter and augment NanoBBS's function, NCOMP is used to configure the low-level system messages, such as the prompts, headers, footers, list formats, menus, and so forth. NCOMP compiles flat text files which are named filename.TXL. It will generate filename.LNG and filename.LDX files which are used by NanoBBS directly. Embedded colours and a number of other embedded commands are allowed in language files, but UFO syntax is not and will be simply written in an ugly manner as though it were text. ┌─────────────┐ │ DISTILL.EXE │ └─────────────┘ This program should be used VERY SPARINGLY - only when absolutely necessary. It scans the NANOBBS.USR file (which contains all the user records) and physically removes any records which are marked "Deleted". I do not recommend running this program because (1) Users above the ones you delete will get new user numbers, which will cause confusion, and (2) As a result of the new user numbers, many users' messagebase Last-Read pointers will be incorrect, causing unbelievable confusion and resulting in a flood of repetitive and negative feedback, and (3) You can always go on an advertising blitz and let the resulting influx of new users overwrite the ones you've marked deleted. Nevertheless, if you have a pressing need to reduce the physical size of your user file, this program will do it (provided you have marked the accounts you want to delete as "deleted"). I have written this program against my better judgment, only because a great number of sysops have requested it. I still think I should have left it to a third party author. Beware! NanoBBS 1.16 Documentation Page 58 ╔═╦════════════════════════╦═╗ ║ ║ External Control Files ║ ║ ╚═╩════════════════════════╩═╝ ┌─────────────────────┐ │ CONFIGURATION FILES │ └─────────────────────┘ ┌────────────┐ │ LIMITS.CTL │ └────────────┘ This file defines the time limits and download limits for each access level. Make sure that all access levels which are in use on your system are included in this file or else you will find some users not getting the access they deserve. The exact syntax of this file is laid out in the example file which comes with NanoBBS. ┌────────────┐ │ EXPIRY.CTL │ └────────────┘ This file defines what happens when a user's account expires. The syntax of this file is explained in the example file. ┌────────────┐ │ CENSOR.CTL │ └────────────┘ This is a list of words which will be censored out of messages posted to areas with the CENSOR option turned on. The example file lists just a few words that I think most sysops will not want to have posted in most areas. You can add or delete any words you like. ┌──────────────┐ │ TRASHCAN.CTL │ └──────────────┘ This is a list of unacceptable user names. If a new user's name is the same as any line in this file the account will not be created and the user will be hung up on. If a line starts with @ (the at sign) then the rest of the line is taken as a substring instead of doing an exact search. Examples: Say your TRASHCAN.CTL file contains: @CRAP @FRUG ALL It will disallow someone named "Joe Crapola" or "Motherfrugger" or "All" but will allow "Allison Smith". For historical reasons, it is a good idea to make "ALL" an unacceptable name. NanoBBS 1.16 Documentation Page 59 ┌──────────────┐ │ FIDOCOST.CTL │ └──────────────┘ This nifty little file is how NanoBBS can do Fidonet netmail costing without a nodelist! Of course, it is left to your mailer to determine whether any of the nodes provided by your users really exist. The syntax is quite simple and is described in full in the FIDOCOST.CTL example included with NanoBBS. ┌────────────┐ │ COOKIE.CTL │ └────────────┘ This is an example input file for the [cookie] UFO keyword. It has a few dozen memorable quotes and song lyrics, and is the one I use personally on THC Freedom Online BBS. ┌───────────┐ │ NODE1.CTL │ └───────────┘ This is the general configuration file for the BBS. See the included NODE1.CTL file for a full explanation of all the options in this file. It must be compiled with the CONFIG.EXE program in order for NanoBBS to be able to use it. This file can have any name, but to use any name other than NODE1, you must use the /C command line option. ┌─────────────┐ │ MSGAREA.CTL │ └─────────────┘ This is the message area configuration file for the BBS. See the included MSGAREA.CTL file for examples and a syntax explanation. It must be compiled with the MMB.EXE program (which is called by the CONFIG.EXE program for your convenience) in order for NanoBBS to be able to use it. ┌──────────────┐ │ FILEAREA.CTL │ └──────────────┘ This is the file area configuration file for the BBS. See the included FILEAREA.CTL file for examples and a syntax explanation. It must be compiled with the MFB.EXE program (also called by CONFIG.EXE) in order for NanoBBS to be able to use it. ┌───────────┐ │ DOORS.CTL │ └───────────┘ This is the configuration file for doors (external games, utilities, etc) for the BBS. See the included DOORS.CTL file for examples and a syntax explanation. It mist be compiled with the MAKEDOOR.EXE program (also called by CONFIG.EXE) in order NanoBBS 1.16 Documentation Page 60 for NanoBBS to be able to use it. ┌──────────┐ │ CHAT.CTL │ └──────────┘ This is the NanoCHAT configuration file. Unlike the other configuration files, it does not need to be "compiled", and so no compiler is included with it. Please see the NanoCHAT chapter for full details on the syntax and usage of this file. ┌──────────────┐ │ MESSAGES.BAR │ └──────────────┘ This is the "Barricade File." Why barricades? Picture this situation: You have a user who's been well-behaved for the most part, perhaps she's uploaded a lot of stuff and sent you a donation. But she happens to get on the wrong side of the moderator of a local echo conference and before she knows it she's barred from posting to that conference. The moderator "directs" you to remove the user's access to the conference, but you don't want to delete the user from your system or reduce her access level; after all she's been a good and valued member of your board. What do you do? Well, in many other BBS programs you'd be between the rock and a hard place; you'd either have to swallow a big lump and reduce the user's access or you'd face the wrath of the moderator and the echomail hub. But NanoBBS has a much less obnoxious solution. It is the "barricade file." The barricade file is a a flat text file containing a list of message areas and the users who are NOT allowed to access them. It takes the following syntax (this is an example): Area 1 The Hacker Joe Schmoe Dave Rhodes Area 15 Tom Vu William J. Clinton Area 16 Dave Rhodes Charlie Manson In this example, "The Hacker", "Joe Schmoe" and "Dave Rhodes" are not allowed to access message area #1. "Tom Vu" and "William J. Clinton" are not allowed to access area 15. Note NanoBBS 1.16 Documentation Page 61 that "Dave Rhodes" is not allowed to access area 1 nor 16. There is one more step required to activate a barricade for an area. In addition to including the area number and the names of the barred users in MESSAGES.BAR, you also must include the BARRICADE parameter in the area's definition in the MSGAREA.CTL file. Don't forget to run MMB or CONFIG when you make this change. The reason for requiring this keyword is that we don't want to check the barricade file _every_ time we change area, only when we are changing to a barricaded area. By imposing this small extra requirement the system can eliminate some unnecessary overhead and will run faster. ┌───────────┐ │ FILES.BBS │ └───────────┘ This is the file used in the file sections to keep track of the files availabel for downloading, and their descriptions. It follows the basic format used in many BBS software packages, with some extensions. Each line in the FILES.BBS is either a file entry or a "comment." To make a line a comment, just make the first character of the line a space. A file entry line starts with the filename and extension (e.g. FILENAME.ASC) followed by a general description of the file. In the classic FILES.BBS scheme, the description must fit on one line, but NanoBBS offers two methods to get around this limit, which we will get to briefly. Here is an example of the FILES.BBS format. This is a comment line. FILENAME.ZIP A generic file listing entry NANOBBS.ZIP NanoBBS, The Ultimate BBS Software Achievement! This is another comment line. Here are some more files. CATCLOCK.ANS An ANSI animated cat clock. MODEMSET.TXT How to set up your high speed modem. NEWGAME.ZIP The latest VGA Shootemup from Violence Games, Inc. Notice how the comment lines are indented? As long as the first character is a space, NanoBBS will display the comment line without trying to find a file. If you inadvertently put in a comment line without the leading space, what will happen is that NanoBBS will attempt to find a file with a filename equal to the first word in your comment. In the above examples, if the comment lines were not indented, NanoBBS would in each case try to find a file called THIS. It would very likely report this file missing. NanoBBS 1.16 Documentation Page 62 EXTENDED FILE DESCRIPTIONS IN FILES.BBS Tilde-style extended descriptions: In FILES.BBS you can have descriptions on the same line up to 240 characters (and they will be automatically word-wrapped), but that's not all! By appending a tilde '~' character to a description, you can indicate that the following line, in its entirety, is also part of the description of the same file! It too will be auto-wrapped and will appear to the user to be one long description. Here is an example, suppose this is a segment from a FILES.BBS: NANOBBS.ZIP NanoBBS: Simply the most flexible BBS on the market!~ Loaded with features! Internal X-Y-Zmodem and SEAlink transfers,~ high speed file searching, internal QWK, an internal full screen~ editor, and the legendary UFO scripting language only begin to~ list the multitude of features in this amazing package! Shareware,~ $69 for one or two nodes. From Whirlwind Software! Notice that the last line does not end in a tilde. This is very important, because if it did, the next line would be counted as part of the description for NANOBBS.ZIP, even if it's really the FILES.BBS entry for the next file in the list! Always remember never to put a tilde on the last line of an extended description! Now, this will come out looking something like this when the user lists the area: NANOBBS.ZIP 760348 94-12-01 NanoBBS: Simply the most flexible BBS on the market! Loaded with features! Internal X-Y-Zmodem and SEAlink transfers, high speed file searching, internal QWK, an internal full screen editor, and the legendary UFO scripting language only begin to list the multitude of features in this amazing package! Shareware, $69 for two nodes. From Whirlwind Software! Pretty neat, eh? You can have descriptions of virtually limitless length using this technique, which is fortunate since so many FILE_ID.DIZ's seem to be just that: endless! Pipe-style extended descriptions: There is another format supported by NanoBBS for extended descriptions. This is sometimes used on CD's, particularly on the Night Owl series. After a FILES.BBS filename and description, the description can be continued by prepending a pipe symbol "|" to the following line. As a matter of practice this should be further prepended with a space but NanoBBS does not require this. NanoBBS 1.16 Documentation Page 63 Here is an example of a valid pipe-style extended description: NANOBBS.ZIP NanoBBS: Simply the most flexible BBS on the | market! Loaded with features! Internal X-Y-Zmodem and SEAlink | transfers, high speed file searching, internal QWK, an | internal full screen editor, and the legendary UFO scripting | language only begin to list the multitude of features in this | amazing package! Shareware, $69 for one or two nodes. From | Whirlwind Software! This example produces a description that looks identical to that of the tilde-style example shown previously. Tilde and Pipe style continuations can be used interchangeably within the same FILES.BBS file but not within the same extended description of an individual file. Although the pipe style is more commonly used by other BBSes, the tilde style is considerably faster, due to the internal structure of the BBS. When NanoBBS extracts a FILE_ID.DIZ to its FILES.BBS file, a pipe-style extended description is generated with a pipe starting each line from FILE_ID.DIZ except the first. ┌────────────┐ │ SEMAPHORES │ └────────────┘ When the user does certain things which are likely to require the services of an external program after s/he logs off (e.g. uploading a file, posting echomail etc.) there has to be a way for the BBS to pass this fact off to the batch file which called it, so that the batch file can in turn call the appropriate upload processor, echomail processor, news mangler, etc. The traditional way that most BBSes accomplish this is through errorlevels. Unfortunately there are only 256 errorlevels, and with five special exit conditions and the possibility of more errorlevels being used by UFO scripts, it quickly becomes apparent that the errorlevel method is inadequate. Therefore, NanoBBS uses semaphores to communicate with the batch file. A semaphore is simply a zero-length file that the batch file checks with an IF EXIST ... line. If the file exists, NanoBBS is indicating a condition. There can be a virtually unlimited number of semaphores versus 256 errorlevels. All of the semaphores are written to the system directory. Here are the possible semaphores implemented so far, where xxx is the node number of the node which generated the file: UFILExxx.SEM - when a user has uploaded any files during the call. You can then run BBS /F to reindex the file section between calls - this is important if reindexing takes a while due to a large file count. NanoBBS 1.16 Documentation Page 64 EECHOxxx.SEM - when a user has entered Fidonet echomail. You can use this to signal to the batch file that it should call Squish, Fastecho, Confmail, TosScan, or whatever you use to pack up your echomail. ENETMxxx.SEM - when a user has entered Fidonet netmail. EMAILxxx.SEM - when a user has entered Internet email. ENEWSxxx.SEM - when a user has entered Usenet news. ╔════════════════════╗ ║ Files in /BBS/MISC ║ ╚════════════════════╝ Please note that in this early release of NanoBBS, most of the .RIP files do not yet exist. NanoBBS will automatically substitute a .ANS or a .ASC file where a .RIP is expected and not found. FSEDHELP.ANS This is only available as a .ANS file, as it is the help screen for the NEd (NanoBBS EDitor) full-screen message editor, which requires ANSI. ┌───────────────────────────────────────────────────────────────┐ │ Where the following files are concerned, NanoBBS is VERY │ │ flexible and VERY forgiving. First, NanoBBS looks for a │ │ compiled UFO file, with an extension of .BBS. Note that │ │ NanoBBS doesn't come with .BBS files for these files; if you │ │ want this option, you must create your own .UFO files and │ │ compile them. Anyhow, if NanoBBS does not find the .BBS file, │ │ it then looks for a .RIP, .ANS, or a .ASC file, as is │ │ appropriate for the graphics standard the user is using, and │ │ it will fall back within these three, e.g. if a .RIP file is │ │ called for and not found, NanoBBS will look for a .ANS and │ │ then a .ASC. Failing these, it tries .TXT, then no extension,│ │ and only after all these have been exhausted does it finally │ │ give up and log an error. │ └───────────────────────────────────────────────────────────────┘ BADNAME.BBS BADNAME.RIP BADNAME.ANS BADNAME.ASC This file is displayed when a user applying for a new account enters a name that has been locked out in TRASHCAN.CTL. You can transplant compiled UFO code into this file. NanoBBS 1.16 Documentation Page 65 BYE.BBS BYE.RIP BYE.ANS BYE.ASC This is the file that is displayed when a normal logoff occurs; it is a sort of "Goodbye, see you soon!" message. You can transplant compiled UFO code into this file. DOORS.BBS DOORS.RIP DOORS.ANS DOORS.ASC This is the file that is displayed when the user goes into the Doors menu. FILEHELP.BBS FILEHELP.RIP FILEHELP.ANS FILEHELP.ASC This provides detailed help for the file section. It can contain UFO syntax. Only FILEHELP.BBS is included. MAINHELP.BBS MAINHELP.RIP MAINHELP.ANS MAINHELP.ASC This provides detailed help for the main menu. It can contain UFO syntax. Only MAINHELP.BBS is included. LOGO.BBS LOGO.RIP LOGO.ANS LOGO.ASC This is the file which is displayed when the user first connects. It is commonly called the "logo screen." WELCOME.BBS WELCOME.RIP WELCOME.ANS WELCOME.ASC This is the file which is displayed after the user has successfully logged on. It is commonly called the "welcome screen." NanoBBS 1.16 Documentation Page 66 ULPOLICY.BBS DLPOLICY.BBS ULPOLICY.RIP DLPOLICY.RIP ULPOLICY.ANS DLPOLICY.ANS ULPOLICY.ASC DLPOLICY.ASC These are the files displayed immediately prior to uploading and downloading, respectively. Normally they would contain advice pertaining to acceptable uploads, ratio enforcement, etc. ┌────────────────────────────────────────────────────────────────┐ │ Random Logo/Welcome Screens! │ │ │ │ Random welcome/logo screens are a popular feature of many │ │ BBSes, but few seem to support it internally as NanoBBS does. │ │ │ │ You can randomize the "logo" files by using the LOGO-RIP.LST, │ │ LOGO-ANS.LST and LOGO-ASC.LST files. You can also randomize │ │ the "welcome" files by using the WELC-RIP.LST, WELC-ANS.LST │ │ and WELC-ASC.LST files. These are plain text files which │ │ contain a list of the files to be randomly chosen from. If you │ │ want to use random welcome files, the LOGO-*.LST files should │ │ be present in your system directory (your "syspath"). If │ │ present, NanoBBS will, instead of displaying a LOGO.* file, │ │ will instead randomly choose a filename from the list. │ │ Otherwise it just uses the appropriate LOGO.* file. The │ │ "welcome" files work in just the same way! Here is an │ │ example of LOGO-ANS.LST, as used on THC Freedom Online BBS. │ │ │ │ THCLOGO1.ANS │ │ THCLOGO2.ANS │ │ THCLOGO5.ANS │ │ THCLOGO6.ANS │ │ THCLOGO7.ANS │ │ THCLOGO8.ANS │ │ THCLOGO9.ANS │ │ THCLOGOA.ANS │ │ │ │ If the filenames in the list have no extension, NanoBBS │ │ assumes that they are located in the same directory with the │ │ other system text files documented in this section (your │ │ "textpath"). │ └────────────────────────────────────────────────────────────────┘ EXPIRED.BBS EXPIRED.RIP EXPIRED.ANS EXPIRED.ASC This file is displayed when a user logs on whose account has just expired. This file is not required as SYSMSG 50 in the language file is used for the same purpose (sysmsg 50 is displayed first). NanoBBS 1.16 Documentation Page 67 NEWUSER1.BBS NEWUSER1.RIP NEWUSER1.ANS NEWUSER1.ASC This is the file displayed prior to the user entering the "new user registration" procedure. NEWUSER2.BBS NEWUSER2.RIP NEWUSER2.ANS NEWUSER2.ASC This is the file displayed after the user completes the "new user registration" procedure. NEWS.BBS NEWS.RIP NEWS.ANS NEWS.ASC This is a "what's new" file displayed right after the "welcome" file has been displayed (see pg. 62) ┌────────────────┐ │ NanoCHAT Files │ └────────────────┘ $I0.BBS $I1.BBS $I2.BBS $I3.BBS $I4.BBS $I5.BBS $IZ.BBS These are the files displayed when a user types /I in NanoCHAT. For example, if the user types /I0, the file $I0.BBS is displayed. Similarly, /I3 would invoke $I3.BBS. /I can be used to invoke files up to six distinct characters long, e.g. /IRULES would invoke a file called $IRULES.BBS, and /ISYSOPS would invoke $ISYSOPS.BBS. Note that these files can be UFO scripts (hence the .BBS extension). You can create as many /I files as you want. $MA.BBS $MB.BBS $MC.BBS $MY.BBS $MZ.BBS These are the files displayed when a user types /M in NanoCHAT. Their operation is identical to the /I files above, except of course that /M files are periodically displayed to the user automatically. Again, full UFO syntax is A-OK, names up to six characters long are fine, and you can have as many as you want. ACTION.HLP This is the help file for actions in NanoCHAT. It isn't a UFO script but it can contain embedded colour codes. NanoBBS 1.16 Documentation Page 68 ACTION.LST This is a short list of actions for NanoCHAT. TOMMCHAT.HLP This is the help file for NanoCHAT. It is a direct copy of the one from TommCHAT, hence its name. NanoBBS 1.16 Documentation Page 69 ╔═╦═══════════════════════════════╦═╗ ║ ║ KEYS WHILE THE USER IS ONLINE ║ ║ ╚═╩═══════════════════════════════╩═╝ ┌───────┐ │ Alt-C │ Chat with the user. ESC exits from Chat. In chat, └───────┘ you can activate a capture buffer (for recording those "memorable" chat sessions) with the Alt-L (Chat Logging) key. ┌───────┐ │ Alt-H │ Hangs up on the user. └───────┘ ┌───────┐ │ Alt-S │ Change the SysOp bar. The sysop bar has several └───────┘ modes which display different information. This key cycles through them. ┌───────┐ │ Alt-E │ Invoke the user editor. The user record of the user └───────┘ currently online will be presented but you can change to another user and you have access to all the functions of the BBS/E user editor. ┌───────┐ │ Alt-F │ "Freeze" or "Unfreeze" time. This key toggles between └───────┘ frozen and unfrozen time. When time is frozen, time limits are not checked and the clock does not tick... however dead-man keyboard timeouts are still in full force. ┌───────┐ │ Alt-J │ "J"ump to DOS. This gets the path and filename for your └───────┘ command.com file straight from the COMPSPEC environment variable so it's automatic. It swaps the program and all its variables out to a swap file (which can take a second or so) giving you the biggest DOS memory window possible. ┌──────┐ │ PgDn │ Takes 5 minutes off the user's time remaining. └──────┘ ┌──────┐ │ PgUp │ Adds 5 minutes to the user's time remaining. └──────┘ ┌────────────┐ │ Down-arrow │ Takes 1 minute off the user's time remaining. └────────────┘ ┌──────────┐ │ Up-arrow │ Adds 1 minute to the user's time remaining. └──────────┘ NanoBBS 1.16 Documentation Page 70 ┌─────┐ │ ESC │ Aborts any file transfer in progress when the current └─────┘ block finishes. In streaming protocols the BBS will wait for the block to be acknowledged by the other end before aborting the transfer, so this may not occur instantly - one end may be several blocks ahead of the other, depending on your FOSSIL buffer size. ┌────────────────────────┐ │ F1 ... F10 │ │ Shift-F1 ... Shift-F10 │ │ Ctrl-F1 ... Ctrl-F10 │ │ Alt-F1 ... Alt-F10 │ └────────────────────────┘ These are 40 sysop-definable keys each of which causes a compiled UFO file (ending in .BBS) to be run. If the file for a particular key is not found an error message will be displayed to the sysop console only. Here are the keys and the filenames they invoke (all the files must be in the BBS System directory): ╔═════════════════════╦═══════════════════════╗ ║ Key Filename ║ Key Filename ║ ╠══════════╤══════════╬═══════════╤═══════════╣ ║ F1 │ F1.BBS ║ Shift-F1 │ SF1.BBS ║ ║ F2 │ F2.BBS ║ Shift-F2 │ SF2.BBS ║ ║ F3 │ F3.BBS ║ Shift-F3 │ SF3.BBS ║ ║ F4 │ F4.BBS ║ Shift-F4 │ SF4.BBS ║ ║ F5 │ F5.BBS ║ Shift-F5 │ SF5.BBS ║ ║ F6 │ F6.BBS ║ Shift-F6 │ SF6.BBS ║ ║ F7 │ F7.BBS ║ Shift-F7 │ SF7.BBS ║ ║ F8 │ F8.BBS ║ Shift-F8 │ SF8.BBS ║ ║ F9 │ F9.BBS ║ Shift-F9 │ SF9.BBS ║ ║ F10 │ F10.BBS ║ Shift-F10 │ SF10.BBS ║ ╚══════════╧══════════╩═══════════╧═══════════╝ ╔═════════════════════╦═══════════════════════╗ ║ Key Filename ║ Key Filename ║ ╠══════════╤══════════╬═══════════╤═══════════╣ ║ Alt-F1 │ AF1.BBS ║ Ctrl-F1 │ CF1.BBS ║ ║ Alt-F2 │ AF2.BBS ║ Ctrl-F2 │ CF2.BBS ║ ║ Alt-F3 │ AF3.BBS ║ Ctrl-F3 │ CF3.BBS ║ ║ Alt-F4 │ AF4.BBS ║ Ctrl-F4 │ CF4.BBS ║ ║ Alt-F5 │ AF5.BBS ║ Ctrl-F5 │ CF5.BBS ║ ║ Alt-F6 │ AF6.BBS ║ Ctrl-F6 │ CF6.BBS ║ ║ Alt-F7 │ AF7.BBS ║ Ctrl-F7 │ CF7.BBS ║ ║ Alt-F8 │ AF8.BBS ║ Ctrl-F8 │ CF8.BBS ║ ║ Alt-F9 │ AF9.BBS ║ Ctrl-F9 │ CF9.BBS ║ ║ Alt-F10 │ AF10.BBS ║ Ctrl-F10 │ CF10.BBS ║ ╚══════════╧══════════╩═══════════╧═══════════╝ NanoBBS 1.16 Documentation Page 71 ╔═╦═════════════════════════════════════════════╦═╗ ║ ║ A TOUR OF THE WFC (WAITING FOR CALL) SCREEN ║ ║ ╚═╩═════════════════════════════════════════════╩═╝ When NanoBBS is waiting for a user, a screen called the WFC (Waiting for Call) screen is displayed. The WFC, done up in stylish shades of blue, is designed to be informative and functional. From the WFC, you can edit users, log on locally, temporarily disable the CD-ROM, and quickly exit back to DOS (much more quickly than most other BBSes!) The WFC displays a lot of information. Most noticeable is the time-of-day clock, with its 6-character-high digits. If the BBS were ever to lock up in WFC, you'd have little trouble telling when it happened. Immediately below the time-of-day clock is a black bar which displays every character that comes in from the modem. This is called the modem viewport. This lets you see what's really going on when NanoBBS answers a call or initializes the modem, so that you can debug your configuration armed with as much information as possible. Control characters, especially Carriage Returns and Line Feeds, are "expanded" into a human-readable form. Below the modem viewport is a 5-line status display. This tells you what NanoBBS is doing at the present moment - initializing the modem, waiting for a call, executing an event, answering the phone, and so on. Most of the time, it says "Now awaiting a call." Below the status display is the Next Event indicator. This lets you know which event is scheduled to be run next and at what time it will run. If you have no events defined, it just says "None." Below the Next Event Indicator, to the left, is a summary of the day's activity. Some information about what happened yesterday is also shown, in parentheses. This summary informs you of the total number of calls to date, the number of calls today (and yesterday), the number of connections today (and yesterday) - including those that don't result in an actual logon, the number of messages posted today (and yesterday), the number of files uploaded today (and yesterday), the number of files downloaded today (and yesterday), the time of the last connection, and the total number of user records in NANOBBS.USR. To the right of the daily summary is a log of the last eight calls to the BBS, including the node number, the username of the caller, the baud rate the user was calling at, the time of the call, and the number of times that user has called in total. NanoBBS 1.16 Documentation Page 72 There are several keys you can use to perform various functions in the WFC. In brief, they are: Alt-C - This toggles the "CD-ROM Out" flag so that users cannot download or list files on your CD-ROMs. This way, you can use your CD-ROM drive for other purposes temporarily - perhaps to play a game or set up a new CD. Alt-E - This invokes the User Editor. The user editor allows you to edit every important field in each user's record. See the next chapter for details on the User Editor. Alt-H - This hangs up the modem. If you have Caller ID and you can see on the display that someone undesirable is trying to connect, you can hang up on them before the modems have even finished negotiating. Or, if (for whatever reason) the BBS exits without hanging up, you can use this to quickly hang up. Alt-I or Alt-R - Either of these keys will re-initialize the modem. Some modems don't always reset properly, with this key you can force a re-initialization and then use the modem viewport and status display to verify that the modem is initialized properly. Alt-L - Local logon. This lets you log on just like a user, only all input and output is to the local console only rather than to the modem. ESC - Escape to DOS. NanoBBS 1.16 Documentation Page 73 ╔═╦═══════════════════════════╦═╗ ║ ║ A TOUR OF THE USER EDITOR ║ ║ ╚═╩═══════════════════════════╩═╝ The NanoBBS internal User Editor is a convenient way to inspect and edit user accounts. When you enter the User Editor from the WFC, you are presented with a display of the first user record in the user file - normally your own. However, if you enter the user editor while a caller is online, the editor shows you the user record for that user instead. There is a great deal of information shown in the user editor screen. In the upper left hand corner, the user's record number and the total number of users is shown, along with the date and time of the first and most recent calls the user has made to your system. Below that is the editable information. Each editable field is preceded with a key, shown in a 3-D highlight, which you can press to edit that field. For example, to edit the user's username, hit the 1 key. The user name field will turn red and blank out, and the cursor will appear there. You can now type in a new name and hit Enter to store it, or you can skip it (preserving the name) by just hitting Enter. The fields are more or less self-explanatory, here is a list: [1] User Name. This is the user's name or pseudonym, and is how the user is normally known to other callers. [2] Real Name. This is the user's real name. It can be the same as the User Name. This is the name that is used in message areas that have the REALNAME keyword active, and is, of course, useful for security purposes. [3] Password. This is the user's password to get into the system. Although the BBS requires users to select a password of four letters or more when they first log on, you can set the password to be any length in the User Editor. You can even create "open" accounts that have no password, just by blanking the password out! [4] Location. This is usually the city and state or province or country the user is calling from. It's always nice to know when callers enjoy your system enough to call long distance. [5] Telephone Number. This is self explanatory. If a user ever loses her password or appears to have been hacked, you'll want to phone her. [6] Access Level. This is the main way in which privilege is dispensed on a NanoBBS system. Generally speaking, the higher the user's access level, the more she can do. You can set minimum access levels for many functions in the BBS. See LIMITS.CTL and the various message base and file area control files for more information. NanoBBS 1.16 Documentation Page 74 [7] Birthdate. This is stored as a string because DOS dates start in 1980. The format is YY-MM-DD. [8] Sex. This can be Male, Female or Undisclosed. Hitting the 8 key toggles between the three choices. If a user is undisclosed, she will have some privacy but she will not be able to enter any message bases that are limited to one sex. Nobody said that privacy is without cost! [9] Keys. There are 32 "keys" which are just boolean flags - on or off. They are designated by a letter or number, 0 to 9 and A to V. They are used to give access to certain functions to specific individuals regardless of (or in concert with) the access level. To edit this just hit 9 and type all the keys you want turned on, leaving out the keys you want off. [A] Downloads. This is the number of kilobytes the user has downloaded. It is with this field that you can identify "leeches." [B] Uploads. This is the number of kilobytes the user has uploaded. [C] Downloads Today. This is the number of kilobytes the user downloaded today, or if she has not called today, then it is the number of kilobytes downloaded on the last date the user did call. [D] Total Calls. This is the number of times the user has logged onto your BBS. As the sysop, you yourself will probably have the highest "total calls" count in the user file. [E] Calls Today. This is the number of times the user has called the BBS today, or if she has not called today, then it is the number of times she called on the last date on which she did call. [F] Time Today. This is the number of minutes the user has been online today, or on the last date on which the user called. [G] Columns. This is simply the number of columns - the screen width. For most callers it should be 80. [H] Lines. This is the number of lines to be displayed between pauses (the "More? (Y/N)" prompts). This is usually 24. [I] Messages Posted. This is the total number of messages the user has entered. [J] Account Expiry. This is the date the user's account "expires" - or is transformed according to the relevant entry in EXPIRY.CTL. See EXPIRY.CTL for more information. If this is set to 70/01/01 (in other words, a value of zero) then the user will never expire. NanoBBS 1.16 Documentation Page 75 [K] Account Credit. If you have the "Credit System" option set in your NODE1.CTL and other config files, then this field holds the amount of credit remaining. It is expressed in cents. [L] Time Bank Balance. Users can deposit time into a "time bank" for later use when they're caught short. This field is the number of minutes the user has stored. [F1] This is the "Suspended" key. It (with the other F-Keys) is a toggle between "on" and "off". When "on" the user may not log on, but the account is otherwise untouched. [F2] This is the "No Limit" key. The user can download as long as she wants and she will never run out of time. Use this toggle exceedingly sparingly! [F3] This is the "No Ratio" key. The user is not subject to upload/download ratios and may download until her modem croaks. [F4] This is the "Rodent" key. All it does is refrain from sounding the chat paging noise when the user tries to page. Most useful for annoying users who, for one reason or another, you don't want to take more drastic action against. [F5] This key toggles ANSi graphics on and off. [F6] This is the "Toast" key. This key allows the user to log on one last time. Before she gets to the main menu prompt, however, a message is displayed stating that "This account has been terminated by the management" (you can make it more or less diplomatic as you choose) and then the user is disconnected and the account is deleted. This is to be used when you want a user to -know- she's been deleted - simply deleting a user might leave them wondering if they've forgotten the password. [F7] This key toggles whether or not NanoBBS will check for personal mail for the user each time she logs on. [F8] This key toggles whether the user uses the Full Screen Editor or the Line Editor when entering messages. [Del] This key marks the user "deleted." The user's account isn't really physically erased, but the user can no longer log on and the account is subject to being overwritten by new users. If you change your mind before a new user account overwrites this one, you can toggle the delete bit off with the same key. That's it for the editable fields! There are some more keys, though, and they are: Left-arrow and Right-arrow: The arrow keys let you move to the next or previous user record. NanoBBS 1.16 Documentation Page 76 Home and End: These keys select the first and last record respectively. Alt-S: This prompts to search for a user. The first time you use this key, NanoBBS needs you to enter a name or partial name to search for. After that, if you just hit [Enter] at the name-search prompt, it will continue looking for the same string. Alt-B: This "blanks out" the currently shown user record, but as a safety measure it will only do this if you have already marked the account "deleted". Alt-R: This "reviews" new users. The BBS quasi-intelligently determines which users are "new" to the system and displays a few important characteristics about each new user, prompting you to promote, erase, skip or edit each one. [S]: This swaps the user's real name and username. Sometimes users get these mixed up. Here you have a one-key fix! [X]: This "mixedcases" the real name and username. Sometimes users enter their information in uppercase characters, resulting in a very unpretty user record. And here you have another one-key fix. [Ins]: This creates a new blank record at the end of the user file. You have to edit its parameters before it'll be much use to anyone. [?] : Hit ? to get a trippy tie-dyed help screen! [Esc]: Hit Escape to get out of the user editor. NanoBBS 1.16 Documentation Page 77 ╔═╦════════════════════════════════════════════════╦═╗ ║ ║ A Tour of NanoBBS's canned main menu interface ║ ║ ╚═╩════════════════════════════════════════════════╩═╝ Here is an explanation of each of the main menu commands. This is taken directly from the MAINHELP.TXT file which is displayed to users who select the "H" (detailed help) option. Because of this, the help is written in a to-the-user perspective. "A" - Jump to a message area. This changes the message area, and is directly synonymous with the "J" command. It is included for the benefit of callers who are used to using "A" to change areas on other BBSes. See the "J" command help (coming up) for more information. "C" - Page SysOp to Chat This option will, during reasonable hours, cause NanoBBS to play a little tune to get the sysop's attention. It is only necessary to page once as a flashing yellow "Paged" will appear on the sysop's console until you log off. The sysop can set the hours during which this option will make noise, so it's probably not a good idea to page late at night. If the Sysop notices that you have paged, and feels like chatting, s/he'll activate "chat mode" which will allow you to communicate directly with the sysop in real time by typing back and forth at one another. "D" - DOORS - Games and other external programs This option will present you with a menu of "doors." Doors are external programs which the BBS can call up for you to use. Most doors are multi-player games. Some of the most popular door games are Barren Realms Elite, Tradewars, Galactic Empire and Rancho Nevada. Each game has its own set of rules and features, and help is (hopefully) available in each one. Detailed help with doors is beyond the scope of this document; ask your sysop or, if there is a message base dedicated to the doors, post a public message there and someone will likely have an answer to your question. "E" - EMAIL - Non-public "electronic mail" This option allows you to send and check for "electronic mail" to other users. NanoBBS's e-mail technology is such that true privacy cannot be guaranteed - the sysop can and probably does read any email on the BBS! However other users cannot read email that is not addressed to them. If privacy is a concern, you should use a program like PGP to encrypt your private mail before sending it to the BBS. Make sure your sysop allows encrypted messages before you try this! NanoBBS 1.16 Documentation Page 78 "F" - FILES - File Transfers On most BBSes this is the most popular place! This is where you can "download" programs, pictures and textfiles (and much more) from the BBS to your computer! You can also "upload" files from your computer to the BBS, which will improve your "download:upload ratio" which the sysop can use to limit excessive downloading. NanoBBS has seven widely-used transfer protocols, and supports advanced features like batch transfers (many files downloaded or uploaded at once) and new-file scans! More help is available at the file transfer menu. "G" - GOODBYE - Log off the BBS Use this command when you are finished using the BBS and want to log off. NanoBBS is robust software; you could just hang up and nothing would be damaged, but it is considered impolite to log off that way, so please use "G"oodbye to log off! This command is available at most menu prompts in the system for your convenience. "H" - HELP - Advanced Help. Advanced Help is what you are reading now. "I" - INFORMATION - Information on various topics This option presents you with a menu of information files for your enlightenment and entertainment. Since this section of the BBS is entirely defined by the Sysop it could contain nearly anything, but normally this will have information about the BBS, its rules, how to subscribe, perhaps a list of other BBSes, etc. "A", "J" - JUMP - "Jump" to another message area This option lets you select which message area you are reading. Most BBSes separate messages into "areas" by subject matter, so if you wish to read messages on a particular subject, use this command to select that subject. These groupings of message topics are called "message areas". "K" - KILL - "Kill" or erase a message This option lets you erase messages written by you. It may occur that you write a message which you later want to erase (for example, you posted a message with hockey scores or other information which you later find out to be incorrect). This command can be a real life-saver in some situations! "L" - LIST CALLS - Display a list of all today's calls to the BBS This option lets you see a list of everyone who's called the BBS since midnight. This is simply for your information. NanoBBS 1.16 Documentation Page 79 "N" - NEW SCAN - Globally scan for new messages This is an extremely powerful messaging command! It displays every new message entered since your last call, in every message area. You can re-read or reply to any of the messages displayed. "O" - OPTIONS - User config options This option gives you a menu of options you can set. It lets you configure the way the BBS looks and behaves when you call. For example, you can change screen size, turn colour on or off, or even change your password! "P" - POST - Post or enter a message in the current message area This command lets you enter a new message in the current file area. You will be prompted for a subject (for example, if you are posting in the fishing echo, you might enter a subject something like "question about bait". The subject is a very brief summary of the message to make it easy for other users to quickly find messages they are interested in. You will also be prompted for an intended recipient. You can put any person's name or handle here, or if the person is a member of the BBS, you can enter their user number. You can also just enter "All" if the message is public and you aren't sending it to any particular person. After that, you will be able to type in your message. The message editors have advanced help screens of their own. Once you are done entering your message, you can save it, edit it, or drop it ("abort"). "Q" - QWK OPTIONS - Interface with the message base via a QWK reader If you have a QWK message reader, you can save a lot of time by downloading messages and reading them off-line in your message reader. You can also reply to these messages in the reader and upload your replies. This has the advantage of letting you use your favourite message editor to enter messages instead of the BBS's line and full-screen editors. It also saves more online time for downloading, playing games, and even for letting other users into the BBS! If you don't have a QWK message reader, you will need one for this menu to be of use to you. Your sysop may have one or more reader software packages available for you to download; if not, try another BBS, such software is widely available! "R" - READ MESSAGES - Read messages in the current area This lets you read and reply to messages in the current message area. NanoBBS 1.16 Documentation Page 80 "S" - SETUP SCANS - Set up the areas you want included in message scans. This lets you define which areas should be included when you do a global [N]ew scan or download messages from the [Q]wk menu. By default ALL messages that you have access to are turned on. "U" - USER LIST - Display a list of users This command lets you look up users on the BBS. It will tell you the user number of a particular user, when s/he last called, and where they are from. You can enter a partial username to do a search for one or more users, or you can just hit Enter and get a list of every user on the system! "W" - WHO'S ONLINE If the BBS has more than one line and the sysop has enabled multi-user operation, this will let you know who is also using the BBS on the other nodes. It will also let you know roughly what they are doing and how long they've been online. "Y" - YOUR STATISTICS This command displays practically everything the BBS knows about you. It will tell you how much you have uploaded, downloaded, and posted, how much time you have banked and how much netmail credit you have left, how many days are left in your subscription, your access level, and much more! If you have a question about your account, check this command before you ask your sysop. "/" - NanoCHAT - Enter the multi-user chat system! If the BBS has more than one line and if the SysOp has enabled multi-line operation, this command will take you into the NanoCHAT multi-user chat system! There is ample help available on the particulars of multi-user chat once you get into that section. "?" - COMMAND SUMMARY - Get a quick list of commands This command is the quick way to remind yourself of the command key for a particular function. "!" - BANG PROMPT - Change the "Bang" prompt This lets you change the one-line message displayed at the main menu command prompt. It is called the "bang" prompt because the exclamation point key used to invoke it is sometimes called a "bang"... "[", "]", "0"..."65535" - QUICK AREA CHANGE In addition to the formal [J] command (change area) mentioned previously, NanoBBS also has two ways to quickly change message NanoBBS 1.16 Documentation Page 81 areas right from the main menu. The open and close square brackets move you down and up one area respectively. Or, you can type in the area number directly. NanoBBS will let you type in up to 5 digits for the area number when it detects that a number key has been pressed! NanoBBS 1.16 Documentation Page 82 ╔═╦═════════════════════════════════════════════╦═╗ ║ ║ Language Files ║ ║ ║ ║ Customize (almost) all of NanoBBS's Output! ║ ║ ╚═╩═════════════════════════════════════════════╩═╝ NanoBBS has the capacity to be a fully multi-lingual BBS. It offers the additional flexibility of having separate ANSI/ASCII and RIP versions of each language. There can be up to 32 languages. See the section titled "The Configuration File" for information on configuring your language files. NanoBBS comes with two language files, but they are not "ready" when you unpack the BBS. These two language files are the ANSI/ASCII and RIPscrip versions of the standard English text for NanoBBS. All language files come in pairs, an ANSI/ASCII version and a RIPscrip version. If the user has RIP but NanoBBS can't find the RIP version of the language file, it'll try to fall back on the ANSI/ASCII version instead. The NanoBBS distribution archive stores the default language as "Update" files, called ENGLISH.UPD for the ASCII/ANSI version and ENGLISH.RPD for the RIPscrip version. When you run INSTALL.BAT, these files are copied into the ENGLISH.TXL and ENGLISH.RXL files, which are the raw language source files. The UPDLNG.EXE program is used to update the language files, so that new versions of the BBS with additional language strings can be integrated with your existing custom language files. All language files end in either .TXL for the "Text" version (the ANSI/ASCII version) and .RXL for the "Rip" version. These files are like the system configuration files in that NanoBBS cannot use them by themselves. They must be "compiled." The program which does this is the NCOMP.EXE program. To compile the English language files, just type NCOMP ENGLISH at the DOS prompt. It will compile both the ANSI/ASCII and the RIP versions of the ENGLISH languagefile. It creates a pair of files for each version. ENGLISH.LNG and ENGLISH.RNG are the actual compiled text for each version of the language files, and ENGLISH.LDX and ENGLISH.RDX contain the index pointers NanoBBS needs to find the language strings within the .LNG and .RNG files. The .LNG and .RNG files are loaded whole into memory for maximum speed. Because of this, there is a maximum size of 65520 bytes. If NCOMP compiles a .LNG or .RNG and the resulting file is bigger than 65520 bytes, it'll be unceremoniously truncated, and calls to chopped-off strings will have unpredictable results. Caveat SysOp! Like the configuration files, the .TXL and .RXL files are just plain ASCII text files. Colour and RIP graphics are achieved by means of embedded colour codes and RIP UFO keywords. See the NanoBBS 1.16 Documentation Page 83 next chapter, "Embedded Colour and Effect Codes", for much more information about these codes and how to use them. Of the UFO keywords, only those dealing with RIPscrip are supported in the language files. You cannot use UFO system variables in the language file with RIPscrip tokens but you can use numeric constants. RIPscrip tokens should not be used in the ANSI/ASCII .TXL file. If you need to be able to access the resources of a UFO script from within a language file string, an embedded command exists that will let you "link" to a UFO script. See the Embedded Colour and Effect Codes chapter, and UFO.DOC, for more information. Here are the first few strings from ENGLISH.TXL, with brief explanations: [languagefile english] [comment the language file must begin with a "languagefile" statement as above, which indicates the language this file represents. Other languages might have a "languagefile francais" or "languagefile deutsch" line instead.] [comment comments appear in a comment statement like this. All comments must begin and end with square brackets as this one does.] [comment this is the first system message in the file. Although other strings can be physically located in random order, this must be physically the first string. It indicates an error condition, that a system string was not found. The ~. (tilde period) embedded command indicates the system string number in question. ] [sysmsg 1] ~PSysMsg Error! Message ~. does not appear in the language file! Please report to sysop! [end] [comment this is used at logon to ask the user for a password. Note the use of embedded commands. The ~@ (tilde at-sign) forces non-stop mode on for the duration of the string, the ~M (tilde M) sets the colour to a nice light blue colour, and the ~■ (tilde, followed by ASCII 254) is a special effect which makes a nice prompt.] [sysmsg 2]~@ ~MPassword ~■[end] [comment This is displayed when the user gets the wrong password at logon. Note the use of a ~V1 embedded command. This is a variable parameter which is context sensitive. In this string, NanoBBS 1.16 Documentation Page 84 it contains the number of tries the user has made at guessing the password. It might have some totally different value or might not even be a number in other strings. But in this case it's a retry counter provided for your convenience.] [sysmsg 3] ~JPassword incorrect. ~G(Try #~L~V1~G)[end] [comment This asks the user for a username, pseudonym, real name, user number, NEW or BYE. In the case of NEW NanoBBS will take the caller through the new-user signup procedure. In the case of BYE, NanoBBS will immediately hang up. If the user is not found, NanoBBS will ask if the spelling is correct - if it is, NanoBBS goes through the new-user signup. Otherwise it goes back to this string and asks the user again.] [sysmsg 4]~@ ~MNew Users: Just type your name or pseudonym to log on! ~OPlease enter your Name, User Number or Handle ~■[end] [comment Here's the string that asks the user if she is a new user. This is displayed when the user's name or number is not found. Note the use of ~V1. In this case it contains the username that was entered at the sysmsg 4 prompt. Totally different from its value in the "Password Incorrect" string! That's what I mean by "context sensitive."] [sysmsg 9]~@ ~L~V1 ~Gnot found. Do you want to register as a new member? [end] ┌───────────────────────────────────────────────────┐ │ Special Embedded Commands for Language Files Only │ └───────────────────────────────────────────────────┘ The following is a long list of special embedded commands that you will find useful - many are already in use in the language files. These commands resemble the embedded colour commands used throughout NanoBBS, but these commands can only be used in the language file. See the next chapter, "Embedded Colour and Effect Codes" for more information on using and entering embedded codes. ~mF : Displays the "From:" (sender) of the current message ~mT : Displays the "To:" (recipient) of the current message ~mS : Displays the Subject of the current message ~mH : Displays the time of the current message ~mD : Displays the date of the current message ~mR : Displays the number of the message to which this one is a reply ~mA : Displays the Number of the Next Reply to the current message ~mC : Displays the Fido Cost (if any) of the current message ~mO : Displays the Fido Origin Address of the Current Message ~mP : Displays the Fido Destination of the Current Message NanoBBS 1.16 Documentation Page 85 ~mX : Displays Message Number of the Current Message ~mY : Displays Message Area's number ~mZ : Displays Message Area's name ~m1 : Indicates if the current message is private ~m2 : Indicates if the current message has been read ~q1 : Displays the time of day in 12-hour HH:MM format ~q2 : Displays the time of day in 12-hour HH:MM:SS format ~q3 : Displays the time of day in 24-hour HH:MM format ~q4 : Displays the time of day in 24-hour HH:MM:SS format ~q5 : Displays am if time is 00:00-11:59, pm if time is 12:00-23:59 ~q6 : Displays the time of day in MM:SS format ~q9 : Displays the user's time left in 24-hour HH:MM format ~qA : Displays the user's time left in 24-hour HH:MM:SS format ~qC : Displays the user's time left in MM:SS format ~qF : Displays the user's time online in 24-hour HH:MM format ~qG : Displays the user's time online in 24-hour HH:MM:SS format ~qI : Displays the user's time online in MM:SS format ~u1 : Displays the user's username ~u2 : Displays the user's real name ~u3 : Displays a pseudo-intelligently determined first name of the user from the username. Words like "The" and "Mr." don't count. ~u4 : Displays the user's gender ~u5 : Displays the user's birthdate ~u6 : Displays the user's city/location ~u7 : Displays the user's phone number ~u8 : Displays the user's per-call time limit ~u9 : Displays the user's per-day time limit ~u0 : Displays the user's required upload/download ratio ~uA : Indicates if the user has clear-screens activated ~uB : Displays the user's access level ~uC : Displays the user's downloads in kilobytes ~uD : Displays the user's uploads in kilobytes ~uE : Displays the user's downloads today in kilobytes ~uF : Displays the total number of calls the user has made to the system ~uG : Displays the number of calls the user has made to the system today ~uH : Displays the amount of time the user has been online today in previous calls, but not including this call. ~uI : Indicates if the user has ANSI turned on ~uJ : Displays the number of messages the user has posted ~uK : Displays the user's actual call:post ratio ~uL : Displays the user's actual download:upload ratio ~uM : Displays the number of columns the user has set ~uN : Displays the number of lines the user has set ~uO : Displays the user's expiry date (if any) ~uP : Displays the number of days until the user's expiry ~uQ : Indicates if the user has no limits ~uR : Indicates if the user has no required ratios ~uS : Displays the date and time of the user's first call ~uT : Displays the date and time of the user's most recent call ~uU : Displays the user's user number ~uV : Displays the verbal description (from LIMITS.CTL) of the user's access level NanoBBS 1.16 Documentation Page 86 ~uW : Displays the user's maximum daily download limit in kilobytes ~uX : Indicates whether the user has "More?" prompts activated ~uY : Indicates if the user is checking for new mail at each logon ~uZ : Inidcates if the user has linefeeds activated (should always be Yes!) ~u& : Indicates if the user has the Full Screen Editor activated ~u, : Displays the language selected by the user ~u; : Displays the user's preferred archiver method ~u. : Displays the user's preferred transfer protocol ╔═╦══════════════════════════════════╦═╗ ║ ║ Embedded Colour and Effect Codes ║ ║ ╚═╩══════════════════════════════════╩═╝ These are available in both the UFO script language and as embedded commands in the language files! Just type in the command as shown below - they all start with the ~ tilde character. On most enhanced AT keyboards, the tilde is the key to the left of the 1 key, a shifted back-quote. The following diagram illustrates where the Tilde key is located... LOCATION OF THE TILDE KEY ON (MOST) AT KEYBOARDS: ─┐ (Remember this is a SHIFTed key!) │ ┌─────────────────────────────────────────────────┘ │ │ ___ ___ ___ ___ ___ ___ ___ ___ └─> | ~ | ! | @ | # | $ | % | ^ | |_`_|_1_|_2_|_3_|_4_|_5_|_6_|_ | |Q |W |E |R |T | |_Tab_|___|___|___|___|___|_ | Caps |A |S |D | |_Lock_|___|___|___|__ | | |_Shift__| <───── Remember to use the Shift key! COLOURS: background foreground ~a Black ~A Black ~I DkGray ~b Red ~B Red ~J LtRed ~c Green ~C Green ~K LtGreen ~d Brown ~D Brown ~L Yellow ~e Blue ~E Blue ~M LtBlue ~f Magenta ~F Magenta ~N LtMagenta ~g Cyan ~G Cyan ~O LtCyan ~h Lt.Gray ~H LtGray ~P White Special ANSi functions and effects: ~1 Clear to End of Line ~6 Blink On ~7 Clear Attributes NanoBBS 1.16 Documentation Page 87 Fade-in: ~< Start ~> End Gray 3D: ~( Start ~) End Cyan 3D: ~{ Start ~} End Prompt : ~■ (ASCII 254) Embedded CR/LF: ~/ Nondestructive clear to beginning: ~\ Destructive clear to beginning: ~| Do a CR/LF only if the cursor is not already at the leftmost column: ~, The following embedded commands are ONLY available in the language file, and may be interpreted literally or give strange results if used in a .UFO script: "Hit Any Key" prompt ~R Send a random cookie: ~& Send the bang Prompt: ~! Make output non-abortable: ~@ Send a beep (^G) to REMOTE user: ~# Embedded CR only (no LF) ~< Automatic two-column alignment: ~> Automatic three-column alignment: ~; {semicolon} Automatic five-column alignment: ~` (backward apostrophe) Tab: ~tnn where nn is column, e.g. ~t45 This example moves the cursor to column 45. Name of current message area: ~i Number of current message area: ~j Name of current file area: ~n Number of current file area: ~o Go to to another SysMsg: ~k### Example: ~k123 goes to SysMsg #123. The SysMsg number must be terminated with a non-numeric character. Call a UFO script (a .BBS file): ~lfilename.bbs Example: ~lextrahlp.bbs runs a compiled UFO script called EXTRAHLP.BBS. The filename must be terminated with a space. This extremely powerful command effectively gives you the full power of UFO from within language files! Languagefile Parameter (can be 1 to 9): ~Vx Example: ~V9 shows parameter 9. ~V1 shows parameter 1. These parameters are sensitive to context and have specific values for each SysMsg, or may be undefined if the SysMsg does not use parameters. See the language files to get an idea of the context for each SysMsg's parameters. NanoBBS 1.16 Documentation Page 88 ╔═╦═══════════════════════════════════════════════════════════╦═╗ ║ ║ NanoCHAT - Setting up NanoBBS as a multi-user chat system ║ ║ ╚═╩═══════════════════════════════════════════════════════════╩═╝ ┌──────────────┐ │ The IPC Disk │ └──────────────┘ IPCs are "Inter Process Communications", which are files shared between nodes in a multi-user system. IPCs are the key to NanoCHAT's operation. NanoCHAT uses IPC files instead of shared memory schemes (which require special device drivers and are NOT always reliable) in order to make NanoCHAT runnable on nearly any system. However, since communications are handled by passing files, DOS can impose quite a burden unless you take steps to speed the files up as much as possible. The best way to do this is to use a RAM Disk. This has the added advantage of not imposing a lot of wear on your hard disk. A NanoCHAT system with several users online can easily created, write, read and then delete dozens of files per second. The wear this would cause an uncached hard disk is extreme. Therefore a RAM disk is essential. The largest possible RAM Disk you can manage should bs used, and your RAMDRIVE.SYS line in CONFIG.SYS should stipulate a large number of files, perhaps 512 or 1024. If you're using a LAN and some of your BBS nodes are on a different machine from the RAM disk, make sure your RAM disk is set up as a network drive so that it is accessible. ┌───────────────────────────────────────────────────────────────┐ │ To enable NanoCHAT and define the path to your RAM disk (or │ │ whatever other kind of disk you may choose to place your IPCs │ │ on) you need to include the following lines in your NanoBBS │ │ config file (NODE1.CTL): │ │ │ │ multiuser │ │ ipcpath f:\ │ │ │ │ The MULTIUSER command instructs NanoBBS to allow the use of │ │ multi-user chat and IPC related functions. │ │ │ │ The IPCPATH command specifies the drive and directory where │ │ the IPC files can be found. It goes without saying that your │ │ config files for each node must specify the same IPC path or │ │ else the nodes will not be able to communicate with one │ │ another. │ └───────────────────────────────────────────────────────────────┘ ┌───────────────────────────────────┐ │ NanoCHAT configuration - CHAT.CTL │ └───────────────────────────────────┘ There are three options to the PROMPT option. ON will display a colourful prompt to remind the user that s/he can type here. NanoBBS 1.16 Documentation Page 89 OFF will more faithfully emulate Diversi-Dial and leave the user's cursor at the leftmost position with no prompt at all. TIME gives the user a unique prompt which displays the current time. prompt off ────────────────────────────────────────────────────────────── The timeout is the amount of time, in minutes, that the user can leave her keyboard idle before NanoCHAT will cut her off. timeout 10 ────────────────────────────────────────────────────────────── This is the interval, in minutes, between automatic postings of the /M messages. msginterval 5 ────────────────────────────────────────────────────────────── The SPEED command sets the interval between checks of the stack files. Generally speaking, this is the "heartbeat" of the program. The interval is in 100'ths of a second, so a speed of 100 would mean that the stacks are checked once every second. A speed of 50 is twice a second and so forth. If NanoBBS Chat places a big drag on your system's overall speed with a low "speed" setting, try slowing it. I have found 15 works fine on my BBS. speed 15 ────────────────────────────────────────────────────────────── This is the number of "votes" required to eject a user in a TeleTrial. teletrial 3 ────────────────────────────────────────────────────────────── These are the access levels passed by the BBS and how they relate to NanoCHAT's six access classes. Any level below that defined for NORMAL is deemed to be m0e access (undesirable or unvalidated users). access normal 40 access vip 98 access moderator 200 access c0 400 access sysop 1000 ────────────────────────────────────────────────────────────── NanoBBS 1.16 Documentation Page 90 As in other chat systems, NanoBBS Chat allows you to quickly indicate a user's "rank" by the brackets around the node number in the /s and other displays brackets m0e ~E: ~E: brackets normal ~G( ~G) brackets vip ~O{ ~O} brackets moderator ~L< ~L> brackets c0 ~P[ ~P] brackets sysop ~J█~b ~7~J█ ────────────────────────────────────────────────────────────── The following are the maximum time limits for each access class. All time limits are in minutes. time m0e 5 time normal 60 time vip 120 time moderator 180 time c0 1440 time sysop 1440 ────────────────────────────────────────────────────────────── Access restrictions - any channels not defined here will be assumed open to everyone! Syntax: Channel {channelnumber} {accessrequired} Example: channel 69 50 This sets a minimum access level of 50 to access channel 69... ────────────────────────────────────────────────────────────── ┌─────────────────────┐ │ Actions and COMPACT │ └─────────────────────┘ Actions are one of the most popular features of advanced chat systems. Basically, actions let you (virtually) -do- things with other users. NanoCHAT's SmartActions contain a library of actions which can be publicly or secretly, adjusting grammatically for the person you're sending to (this is why NanoCHAT needs to know each user's sex). Generic Actions are nowhere near as advanced as SmartActions but they can be made to "do" just about anything. In this section we will concentrate on configuring SmartActions. SmartActions are defined in the file ACTIONS.CTL. NanoBBS 1.16 Documentation Page 91 In order for actions to be used, they must first be compiled with the COMPACT (COMPile ACTions) program. Just type COMPACT when you've finished making your changes to ACTIONS.CTL. There can be up to 256 actions from 0 to 255. Let's have a look at an example from the default ACTIONS.CTL: action 1 command wink access 10 see me You wink. see me2 You wink at ~r. see all ~s winks seductively! see all2 ~s winks seductively at ~r! see all3 ~s winks knowingly at everyone! see you ~s winks seductively at you~t! see noaccess Your eyelids seem to be stuck! end As you can see, each action is started with the keyword ACTION followed by the action number (0 to 255). The COMMAND keyword specifies the /a command necessary to invoke the action. In this case the command is "wink" so the user would type: /a wink ...to activate the command and wink at everyone. The "See" fields can be up to 80 characters including embedded ~ codes. SEE ME pertains to what you see when you perform your action for no recipient or for ALL. SEE ME2 pertains to what you see when you perform your action for a specific user. SEE ALL pertains to what everyone sees when the user types the command with no recipient. This may mean the action is done to all users, to nobody, or to the user herself. SEE ALL2 pertains to what everyone sees when the user types the command with a specific person as the recipient. For example: /a wink tommy ...would cause everyone to see: Joanie winks seductively at Tommy! ...except Tommy who would see: Joanie winks seductively at you! NanoBBS 1.16 Documentation Page 92 (see SEE YOU below). SEE ALL3 pertains to what everyone sees when ALL is the recipient. This means that the action is performed for everyone present. SEE YOU pertains to what the recipient of an action sees. See the SEE ALL2 example above. SEE NOACCESS is what the user sees if s/he tries to use an action they don't have access for. There are several ~ codes peculiar to intelligent actions (these only work within actions): ~r - Recipient's handle ~s - Sender's handle ~t - " secretly" if secret, nothing otherwise ~u - selected sender pronoun/noun ~U - selected recipient pronoun/noun Pronouns by number: If user is male/female: 1: he/she 2: his/her 3: his/hers 4: him/her 5: boy/girl 6: girl/boy 7: man/woman 8: woman/man 9: dude/babe These pronouns can also be specified by name if typed exactly as shown above. See ACTIONS.CTL for several live examples of the use of selected pronouns. Grammaticists: Yes, I know most of these are nouns - we hackers like to suppose things to save time... ┌──────────────────────────────────┐ │ User and VIP Functions In Detail │ └──────────────────────────────────┘ The most important key for users, VIPs and co-sysops is the forward slash key "/". All commands are preceded by the slash, and all are illustrated in this manual with the slash and command as they should be typed. NanoBBS 1.16 Documentation Page 93 ┌─────────────┐ │ Public Chat │ └─────────────┘ Public "Chat" is the most basic function offered by NanoCHAT. Anything you type that is not preceded by the slash ("/") character is presumed by NanoCHAT to be a public statement. For example, if you were to simply type: Hello There. Everyone on your channel would see "Hello There." along with your handle and node number. ┌──────────────────┐ │ Private Messages │ └──────────────────┘ Often it is desirable for users to carry on private conversations without leaving public channels. This can be accomplished by using the /p command. For example, if there is a user on line 12, and you wanted to privately say "Hi, Chuck!" to that user, you would type: /p12 Hi, Chuck! That user would see your message, along with your handle and node number, and would be informed that it is a private message. If there is no-one on the node you specify, NanoCHAT will inform you of this fact. ┌───────────────────┐ │ Changing Channels │ └───────────────────┘ /t - Change "Channel" - NanoCHAT supports 256 "channels" so that separate discussions can be carried out without interference or confusion with other conversations. Include the channel number you want to change to, example: /t42 ... this will take you to channel 42. Only other users on channel 42 will be able to see what you publicly type. By default, you start out on Channel 1. NanoBBS 1.16 Documentation Page 94 ┌─────────────────┐ │ Generic Actions │ └─────────────────┘ /ga- "Generic Action" - crudely mimics a popular feature of other chat systems. This command causes the system to make a third-party statement about you. Here is an example: /a is laughing her fool head off! This might cause the following to be displayed to everyone on your channel: Pebbles is laughing her fool head off! ┌───────────────┐ │ Smart Actions │ └───────────────┘ Here is a list of default available actions: agree back bearhug beer beg belch bite blush bonk bow brb cheer chill chuckle claw comfort cough crotchkick cry curtsy dance demand duck duh embrace evilgrin faint fallinlove fart finger flash flirt french frown gasp glare grin groan gross handshake hi5 impure innocent kick kickass kill kiss laugh lick lie loogy look love lust moan moo moon naked niceass nod puke punch purr re rip rose scream secret shrug sing smack smirk smoke smooch snicker spank streak strip thank think toke tongue trudeau ttyl wave wink yawn /a Invoke an action. You can invoke actions with no parameters, or you can specify a user (by name or node) you wish to perform the action on, or you can specify ALL to do it to everyone on your channel! You can also do an action to a user secretly! Exemplia: /a hug Tommy This might produce the following output for all users: Cuddlez hugs Tommy close! ...except for the recipient who sees... Cuddlez hugs you close! NanoBBS 1.16 Documentation Page 95 /a tickle Cuddlez secretly This would not produce a message for anyone except the recipient and the sender. The recipient would see something like this: Tommy is secretly tickling you silly! /a bonk all ...this might produce something like... Tommy is bonking everyone over the head! SmartActions might use personal pronouns like She or He - these are automatically inserted correctly for the sending and receiving party's gender! If you would like to experiment with SmartActions, try performing them on yourself or in public on an empty channel, so as not to clutter busy channels... Type /al for a list of actions. ┌────────────┐ │ Squelching │ └────────────┘ /x - "Squelch" - Disallows /p messages from a user. To sqelch someone type /x followed by their node number, e.g. /x2 This will stop whomever is on node 2 from sending you /p messages. To allow a user to /p again, or "unsquelch", simply repeat the command, e.g. /x2 a second time will unsquelch node 2. /xa- "Squelch All" - Disallows /p messages from all users! This will actually squelch everyone who is on at the time, however if someone logs off and comes back, they will be able to /p you again. You can unsquelch everyone by typing /xa again, and you can selectively unsquelch certain users using the above /x command. ┌─────────────────┐ │ System Messages │ └─────────────────┘ /mxxx This displays one of the system messages which are automatically displayed from time to time. xxx can be NanoBBS 1.16 Documentation Page 96 any combination of 1 to 7 alphanumeric characters. This is called the "slot name" of the message. It corresponds to a textfile on disk. If a message is displayed as /ma, its filename is MA.TCH. Example: /ma will display the /ma message (if present). Users can be assigned message slots online using the co-sys0p command /ka (see the "Sysop and Co-Sys0p Functions" section of this manual). A user who has been assigned a slot may edit its contents by typing /m+ xxx ... where xxx is the slot name. If the user specifies the wrong slot name an error is reported. Once this command is accepted, the user then sends up to 16k of ASCII or ANSI text terminated by ^Z (ASCII 26). When the system receives the ^Z the message is saved. It can then be seen by typing /mxxx (xxx being the name) and will appear automatically during the random /m messages. There is a special kind of system message called an information file. This is exactly the same as a /m message except that it cannot be assigned to a user. It is accessed by typing /ixxx ...where xxx is the name, similar to /m messages. /i messages are used for static information about the chat system, e.g. its rules, its technical information, etc. /m messages are normally displayed at random during regular intervals, defined by the SysOp. Users can turn these automatic messages off by typing: /m- ┌────────────┐ │ Tele-Trial │ └────────────┘ /tt nnn A TeleTrial is a quick-and-dirty vote taken by ordinary users to have an annoying user ejected from the system, where nnn is the node number of the user to be booted. Once enough votes are cast, the user is history. Only one vote per user. NanoBBS 1.16 Documentation Page 97 ┌────────────────────────────────────┐ │ Summoning Callers Outside NanoCHAT │ └────────────────────────────────────┘ /pg or page By typing the word page by itself in NanoCHAT, the caller can invoke the user paging feature, in which the caller can "page" another caller to NanoCHAT. /tg or telegram By typing the word telegram by itself in NanoCHAT, the caller can send a user on another node a 255-character "telegram". ┌─────────────────────────┐ │ Miscellaneous Functions │ └─────────────────────────┘ /? - This command displays the user help file, with a concise explanation of each command. /q - "Quit": This command exits NanoCHAT and returns the caller to the BBS. /s - "Status": This command displays a brief summary of all users who are using NanoCHAT. It displays the channel number, node number, and handle of each user as well as indicating which nodes are squelched or muted, and which ones have the caller squelched. /sm - "Show Members": This command displays a list of all users in NanoCHAT's user database. /h - "Handle": This allows the caller to change her/his handle. It can be changed for the current call only, or saved permanently in the user database, if the caller chooses. Users may include embedded colour codes in handles. /u1 - "Hello Message": This allows the caller to change the message displayed by the system when s/he logs on. It may contain embedded characters and can be up to 96 characters in length. If no string follows, the message is replaced with the default message defined by the sysop. /u2 - "Goodbye Message": This allows the caller to change the message displayed by the system when s/he logs off. Like the "Hello" message it can contain up to 96 characters. NanoBBS 1.16 Documentation Page 98 ┌─────────────────────────────────────┐ │ SysOp and "c0" (Co-SysOp) Functions │ └─────────────────────────────────────┘ There are 6 access classes in NanoCHAT: Sys0p (highest) Co-Sys0p Moderator VIP Normal m0e (lowest) ┌────────────────────┐ │ Moderator commands │ └────────────────────┘ /k? Display a command list for moderators, c0-sys0ps, and sys0ps. /kx nnn Eject user on node nnn - This will inform the user in question that s/he's being tossed, and will then exit the chat door. /kj nnn Jail user on node nnn - This will prevent the user from changing to another channel /km nnn Mute user on node nnn - This will cause the user's task to ignore any public messages, private messages, or actions s/he may attempt. ┌───────────────────┐ │ Co-Sys0p commands │ └───────────────────┘ (Note: Co-Sys0ps also have access to moderator commands) /k+ nnn Promote user on node nnn - This temporarily increases the user's access level to the next class. M0es are made normal, normals VIP, and VIPs moderators. The maximum level allowed by this command is Moderator. /k- nnn Demote user on node nnn - This has the opposite effect of /k+. Other c0-sys0ps (and sys0ps) are unaffected by this command. /ky nnn Rudely eject user on node nnn - This is very similar to /kx, but it will simply hang up on the user without an explanatory message of any sort. NanoBBS 1.16 Documentation Page 99 /ka nnn yyy Set /m slot for user on node nnn - This will assign a message slot to the user on nnn, where yyy is the message name. yyy can be from 1 to 7 alphanumeric characters in length. This assignment is saved in the user's userbase record and is the only field editable by non-Sys0p c0's. /ka nnn Revoke /m slot for user on node nnn /ka with no slot name will render the user unable to modify any /m slot! /kd nnn De-stat user on node nnn This is a somewhat technical command which should be used when, for whatever reason, a user leaves chat but still shows up in the /s list. That non-user could continue receiving messages from other nodes until the IPC drive fills, which would cause problems for the whole system, therefore c0's may forestall such problems with this command. It will also delete any dead IPCs which have accumulated for the user. /kh nnn <handle> Temporarily change handle of user on node nnn to <handle>. This is useful when a user chooses an unacceptable handle. /kt nnn ttt Temporarily change user's channel to channel ttt (where ttt is a valid channel from 1 to 255). You can keep the user there by "Jailing" her. ┌────────────────┐ │ Sys0p commands │ └────────────────┘ (Note: Sys0ps have access to ALL system functions including moderator and co-sys0p functions) /k* nnn Temporarily grant/revoke Co-sys0p access for node nnn. When access is revoked the user's access returns to the access level the user logged in with. /kb nnn "Bar" a user on node nnn and eject. This is identical to /ky except that prior to hanging up on the user, the system will add the user's BBS name to a "barred" file or blacklist will then prevent the user from using the door again until the name is removed from the blacklist. The blacklist is a NanoBBS 1.16 Documentation Page 100 simple textfile which can be edited in any text editor (you may add, remove, or modify names this way) with the filename NanoCHAT.BAR. /ke uuu Edit user record for user number uuu uuu is a user record number, not a node number! You can edit any user this way, regardless of whether s/he is online at the time. If the user is online, the changes you make will apply to them immediately! To find a user's user number, the user command /sm will display the user number of each user. /ks System Status. This will display the number of callers online, the number of bytes free on the IPC and system drives, the size of available memory, the number of /m messages available, and the total number of users in the userbase. NanoBBS 1.16 Documentation Page 101 ╔═╦═══════════════════════════════════════════════════════════╦═╗ ║ ║ GLOSSARY ║ ║ ╚═╩═══════════════════════════════════════════════════════════╩═╝ Here is a list of some of the technical terms used in the NanoBBS documentation, along with some terms you're likely to encounter as a sysop. ARC - An older archiving program by SEA (System Enhancement Associates). This program is no longer widely used to archive software on BBSes but is still the only recognized archiver for FidoNet echomail transfers. ARJ - An archiving program by Robert K. Jung. Not as widely used as ZIP, its compression and speed are competetive and its registration price is a little cheaper. ANSI - This term is a sort of misnomer. In sysop usage, it refers to IBM's colour version of the DEC VT-100 terminal command language. This protocol is what gives most BBSes their colour menus and screens. Virtually all terminal programs written for the IBM PC support this standard and default to it. Baud - A term which refers to a change in the signal state in a modem's modulation. Baud and BPS (modem speed) used to be the same quantity when 300 baud was standard, but today's advanced modulation schemes are able to attach many bits to each baud to increase real speed (BPS). Baud and BPS are still used interchangeably in common conversation, but they are no longer the same and you'll likely be indignantly corrected by certain smug gurus if you should accidentally post something which suggests that they are... BBS - Bulletin Board System. An online service, usually run on a single PC or a local area network of PCs. NanoBBS is a software program which can turn your system into a BBS. BPS - Bits per Second. The speed of your modem. This is not to be confused with Baud, which is an inaccurate name for modem speed. Nevertheless, Baud is more commonly used so it's generally acceptable to talk about a "14400 baud" modem even though there's no such thing. It's 14400 BPS, but only 2400 baud (it moves 6 bits per baud) Chat - There are two types of Chat. The kind most sysops are familiar with is "sysop chat" where the sysop hits Alt-C and "breaks in" to type in real time to the user, who can type back. NanoBBS also supports "teleconference chat" via NanoCHAT. The best BBS software packages support teleconference chat, and most BBSes with two or more lines have it implemented in one form or another. NOTE: There are so many technical and not-so-technical terms dealing with teleconference chat that I could devote a whole glossary to just them. However, they are well NanoBBS 1.16 Documentation Page 102 covered in the chapter on NanoCHAT. Doors - Doors are external programs, usually games, that the user can run from the BBS. The attraction to doors is that they allow many people to play the same game and compete with each other, while most video games are limited to one or two players. Although most doors are games, many have other functions such as taking surveys, match-making, and providing a .QWK mail interface, to name but a few. Download - Downloading is what happens when the BBS sends the user one or more files at her request. Echomail - A type of shared message area. Through the use of a Fidonet Technology Mailer and an Echomail Packer, you can "share" message areas with other BBS, so that your users and users of other BBSes can converse on the same subject without all the parties having to call all the BBSes. A message posted on one BBS in the echo network is automatically posted to the same area on all the other participating systems. Some echoes are very popular and are shared by hundreds of systems, and have hundreds of messages posted to them every day! Echomail Processor - This is a program which, after your Fidonet mailer has received echomail packets, unpacks the packets and processes them into a form useable by NanoBBS. It also checks the message bases to see if you or your callers have entered any new messages, and if any new messages exist, it packs them up and prepares them to be sent out to the net by your mailer. FILE_ID.DIZ - This is a small text file that is often found inside ZIP archives. It is used to describe the contents of the ZIP archive and is usually imported directly into the BBS's FILES.BBS file lists. The extension DIZ stands for "Description In Zip". FOSSIL - A FOSSIL is a standard serial port device driver. The word FOSSIL is an acronym which stands for Fido Opus Seadog Standard Interface Layer. In the early days of Fidonet, many computers were only partially IBM compatible, and serial port compatibility among these old machines was a particularly difficult point. So, it was decided by several online software authors (among them Fido, Opus and SEADog) to create a standard serial port interface for which any software could be written. The interface is serviced by a device driver - the FOSSIL. Then, the creation of FOSSILs was left to the manufacturers and users of the various quasi-compatible machines, and the end result was that if a FOSSIL existed for your machine, it could run any FOSSIL based software. Today, FOSSILs are used mainly for the convenience of BBS and door authors, but they still serve their original NanoBBS 1.16 Documentation Page 103 purpose now that FOSSILs are being written for non-standard multi-port serial cards. X00 by Ray Gwinn and BNU by David Nugent are perhaps the two most widely used FOSSIL drivers. FSE - Full Screen Editor. This is a part of NanoBBS that lets you enter messages in a convenient full-screen environment similar to a word processor. The alternative is an old-fashioned line-by-line editor, akin to DOS's Edlin program. Some other BBSes need an external program to support an FSE, but NanoBBS has one called NEd (NanoEditor) built in! FTN - Fidonet Technology Network. This is a network of BBSes which uses the protocols and software developed originally for Fidonet. There are many FTNs including, of course, Fidonet. These networks cover the spectrum from general interest chat type networks to very specialized subject matter. Joining an FTN requires, at minimum, a mailer such as BinkleyTerm or Intermail, an echomail processor such as Squish or FMail, and a Fidonet compatible BBS such as Maximus-CBCS. .GZ - GZip is a portable compression method used mainly on Unix systems. An MS-DOS version is available on many FTP sites. Leech - A derogatory term used by sysops to describe users who only download and never post messages or upload. This term is used mainly by sysops who run free BBSes. If you're running a BBS for profit, you need to take a whole different attitude. LZH - An archiving method by Haruyasu Yoshizaki (the program is called LHA, even though the file extensions are LZH). Competitive compression and speed, and freely distributable and usable by noncommercial users! Mailer - Sometimes called a Front End Mailer or a Front Door (hence the name of that particular mailer product). A Mailer is a system which is responsible for communicating with Fidonet and other fidonet-technology networks. Usually, it answers the phone, determines whether the call is a mail call or a BBS call, and brings up the BBS if it's a BBS call. If it's a mail call, the mailer will receive any incoming mail, send any outgoing mail that may be waiting to go to the system that is calling, and then finish the call, exit the mailer back to a batch file, which runs other programs necessary to process the mail. If you are in Fidonet you will need a mailer and an echomail processor in order for NanoBBS to properly handle Fidonet netmail and echomail. Modem - The device which converts digital data into audible sounds (or their electrical equivalents) which can be transmitted over the phone lines, and then back into data again. One of the most basic hardware requirements for a BBS. NanoBBS 1.16 Documentation Page 104 Offline Reader - This is a program which lets a user read her messages after she has logged off of the BBS where the messages came from. The user logs on to the BBS, downloads all the new messages at once, then logs off and uses the offline reader to read them at her leisure. This cuts down on connect time, and is more convenient for the user. Page - The act of summoning someone on a BBS for live "chat". NanoBBS has two kinds of page: SysOp paging, in which NanoBBS plays a little tune to get an inattentive sysop's attention, and user chat, in which callers can electronically page each other online and rendezvous in NanoCHAT. QWK - A message format developed for PC-Board systems. This format is mainly used for offline readers (see above). NanoBBS supports this, of course. RIP - Remote Imaging Protocol. This is a graphics display protocol used in some of the more recent BBS and terminal programs - including NanoBBS. RIP allows you to build highly complex graphical menus and screens, and lets your user point-and-click their way around your BBS. If you want your BBS to appeal to the "all thumbs" type user, you definitely should seriously consider setting up NanoBBS for RIP support! Semaphore - A semaphore is a file, usually zero bytes in size, that is written to indicate to a batch file or to another program that the other program has to do something. Often semaphores are the only way for unrelated programs to communicate with each other. Shareware - A try-before-you-buy software marketing concept. Software is distributed publicly with little or no documentation and usually with several important features disabled. If users like the program they are expected to pay for the full version, which is normally shipped by mail with the full packaging, documentation, technical support and other goodies. NanoBBS is distributed as shareware. SysOp - The person who runs the BBS. In short, YOU. This word is a contraction of SYStem OPerator. You may elect to appoint co-sysops, who have equal control over the BBS, assistant sysops who are able to carry out basic housekeeping functions, and moderators, which are really just regular users who can delete messages from other users and are politically empowered by you to maintain decorum. NanoBBS 1.16 Documentation Page 105 Telegram - a short message (under 255 characters) sent from one user to another while both are online on a multi-node system. Telegrams are a one-shot alternative to going into chat and let users communicate while they're browsing in menus. Terminal - That's the program a user uses to call your BBS. Some of the best are QmodemPro from Mustang Software, and Telix from DeltaComm. Both are promoted heavily on BBSes by their publishers. Special-purpose terminals like RipTerm should always be made easily accessible to users if your BBS supports their special protocols. Make sure you have the shareware test-drive versions of major terminal programs easily available to new users, so that they can upgrade right away from the second-rate terminal programs that usually come with modems at the time of purchase. Trashcan - A control file used by your BBS to detect problem users and reject them. When you have to remove a problem user, you put her name and known aliases in this file and the BBS will reject any logon with those names. It is considered a measure of a sysop's success as a diplomat if her trashcan is empty... Twit - A term used by sysops to describe a problem user. Not to be confused with Hacker. Upload - Uploading is when a user sends the BBS one or more files. Usenet - A set of "newsgroups" which are actually not unlike FTN echoes, but are usually moderated. These are propagated through the internet rather than through phone lines as FTN echoes are. Usenet newsgroups exist for virtually every conceivable field of interest. If you have a full Usenet feed, your users will never have a shortage of messages to read, but you may develop a shortage of disk space! WFC - Waiting For Call. This is what the screen displayed by the BBS while waiting for a call is called. If your BBS is successful, you'll see very little of the WFC screen. Xmodem - A very old file-transfer protocol, Xmodem is nearly extinct. It is a block transfer protocol which sends files in blocks of 128 bytes, waiting for acknowledgement (and a checksum) before sending the next block. In the real world, the best efficiency you can hope for is about 75%, but it's usually worse than that. Users should be discouraged from using Xmodem - point them to a terminal program that supports Zmodem, and ask that they download (and use) it. Once the user has tried Zmodem, she'll never want to go back - mention something to that effect while you're trying to talk the user into changing terminals! NanoBBS 1.16 Documentation Page 106 .Z - Files compressed by Unix systems often have a .Z extension. There are Unix uncompressors for most platforms including MS-DOS. ZIP - A file compression method developed by Phil Katz. This is probably the most common method used by PC users. Compression ratios in the latest versions are excellent; this format is well worth standardizing your BBS to. Some BBSes will not accept uploads with any other archiver! Zmodem - A very popular file-transfer protocol. Zmodem automatically transfers files from one computer to the other with full filename and date preservation, and includes a "resume" feature in case the transfer is cut off. It is also very efficient, because it is a "streaming" protocol - it doesn't wait for acknowledgement of each block before sending another. This allows efficiencies very close to 100%. Zoo - A very portable compression method. You might see files created on Macintosh, Amiga or Unix-based computers but intended for multiple platforms, compressed in this format. It's slow and not as efficient as other archivers but it's available for nearly every platform I've seen. NanoBBS 1.16 Documentation Page 107 ▄█████▄ ▄█████▄ ▄█████▄ ▄████▄ ▄█████▄ ▄█████▄ ▄████▄ ▄▄▄ ▀███ ▄▄▄ ▀███ ▄▄▄ ▀███ ▄▄▄ ▀███ ▄▄▄ ██▀ ▄▄▄ ██▀ ▄▄▄ ▀▀▀ ███ ███ ███ ███ ███ ███ ███ ███ ██████▄ ██████▄ ▀████▄ ███ ███ ████████ ███ ███ ███▄ ███ ███ ███ ███ ███ ▄▄▄ ███ ███ ███ ███ ███ ███ ███ ▀████▀ ██████▀ ██████▀ ▀████▀ NanoBBS 1.16 Copyright 1993-1996 Whirlwind Software All Rights Reserved ─────────────────────────────────────────────────────────────── Contact Information: Mail: Whirlwind Software P.O. Box 5874 Victoria, B.C. Canada V8R 6S8 E-mail: ue075@freenet.victoria.bc.ca CompuServe: 76722,2330 Fidonet: 1:340/26 BBS: +1 604 361 4549 (300-33600 bps, 24 hours) Voice: +1 604 361 1820 NanoBBS 1.16 Documentation Page 108